Статья о том, что иногда надо смотреть на свой продукт не как на «добро», а скорее «неизбежное зло».
Это вольный перевод. Хотя я старался сохранить общий смысл текста, некоторые выражения могут звучать не совсем как в оригинале. Спасибо за внимание.
Софт сейчас буквально повсюду. Современное общество от него зависит. Он внутри часов, медицинского оборудования, телефонов, телевизоров, лифтов, машин, и даже «компьютеров» (как будто остальные девайсы ничего не вычисляют [игра слов: англ. compute — прим.перев.]).
Будучи консультантом, я помогаю фирмам разрабатывать программное обеспечение вот уже 14 лет, и немного программирую для себя.
Я соавтор международного стандарта, и также помогал воплотить его в жизнь. Я писал софт для управления спутниковой системой связи. Я разрабатывал инструменты для команды, которая создавала модель Европейского сверхбольшого телескопа. Я участвовал в софтовых проектах для автопрома, систем здравоохранения, банков, страхования, телекоммуникаций, авиации и многих других.
В некоторых компаниях разработка шла неплохо. Команды сдавали проекты отличного качества. Акционеры были счастливы. Фирмы наращивали свою клиентскую базу и прибыль.
Но другим приходилось туго. Я видел войны между отделами за право вставить свои пять копеек в требования к релизу. Видел, как разрабы не поспевали за раздуванием фич и за заявками на изменения. Некоторые из них вообще перестали видеть смысл в том, что делали.
Я наблюдал за тем, как пропадало понимание между разработчиками и акционерами-нетехнарями, которые ими руководили.
Через несколько лет я распознал этот паттерн, и теперь когда люди спрашивали меня, что же пошло не так, я начал отвечать им: просто никто не хочет пользоваться ПО.
Сперва люди принимали меня за сумасшедшего. Ведь программы повсюду, они рулят цивилизацией! Но когда я объяснял, что имею ввиду, многие из них начинали озадаченно кивать головой.
***
Наверняка вы, как и я, хоть раз делали покупки в интернет-магазинах.
Хотите ли проходить регистрацию в ещё одном из них?
Нравится ли вам добавлять товары в корзину один за другим?
Или каждый раз перепроверять, правильно ли ввели номер кредитки?
Мне вот не особо.
И все же, я покупаю через интернет. Но почему?
Достижение желаемого результата
То, что я хочу получить, это желаемый результат: я хочу купить новую стиралку или почитать новую книжку. Каждое взаимодействие с софтом — это шаг между мной и этим результатом.
Осознание этого в корне поменяло мой подход к разработке.
Многие компании измеряют продуктивность разработчика по количеству строк кода, или по скорости, грубо говоря, число сделанных фич за единицу времени, умноженное на их размер.
Некоторые люди не видят разницы между продажей функционала и продажей апельсинов. Больше фич дал клиенту — больше денег получил.
Но на самом деле это не так.
Добавление функционала может упростить или, наоборот, помешать вашему пользователю получить желаемый результат. А может и вовсе сделать это невозможным. Есть другие, более полезные метрики, чем скорость разработки.
Когда вы выходите на новый рынок, убедитесь, что ваш продукт удовлетворяет какую-то потребность клиента. Хольте и лелейте своих клиентов и собирайте фидбек почаще. Не превращайте свой программный продукт в никому не нужную кашу, раздувая его функционал.
Если у вас уже есть своя ниша, тогда упрощайте. Сделайте путь пользователя к желаемому результату как можно более коротким и приятным, потому в конце этого пути ваша компания получает свой доход. Хорошо, если вы дадите пользователю то, что ему нужно, за меньшее число шагов. Разрабатывайте меньше, ведь разработка софта — это инвестиция.
Как Amazon Kindle сокращает ваш путь к желаемому
Амазон в свое время начинал с продажи книг онлайн. Вы покупали у них книгу, и они доставляли её до вашей двери.
Потом они первыми сделали покупку в один клик, позволяя не вводить каждый раз свою платёжную информацию и кликать много раз для подтверждения каждого заказа. Это сократило путь пользователя.
Позже они представили Kindle. Это ещё сильнее сократило пользовательский путь: находим книжку, смотрим аннотацию, подтверждаем покупку. Немного ждем, пока скачается, и книжка у нас. Не надо ждать курьера. В конце концов это всё ведет к тому же, что и в первые дни жизни Амазона: вы можете прочитать книжку. Просто путь к ней стал гораздо короче.
Нельзя стать успешным, думая лишь о количестве фич. К счастью, я не единственный, кто так считает.
Гойко Аджич придумал Impact Mapping — подход к формированию функционала из бизнес-целей. Он призывает сообщество разработчиков «Производить эффект, а не софт» (“Make impacts, not software”).
Дэвид Хейнемейер Хансон, создатель Ruby on Rails, уверен, что всегда можно сделать меньше.
Когда я объясняю это разработчикам, они меня понимают, но лишь немногие компании воплотили в жизни философию сокращения пользовательского пути.
Так что не поймите меня неправильно: я люблю программное обеспечение. Оно меня потрясает. Я начал создавать программы в ранние 90е, и до сих пор тащусь от этого.
Софт полезен. Но не сам по себе. Софт — это всего лишь средство для получения желаемого.
Пожалуйста, помните это.
Комментарии (63)
Nekto_TM
16.09.2017 13:18+5Старая как мир истина, которая обсасывается в различных изложениях и трактовках ооочень давно. «Лучший интерфейс — отсутствие интерфейса», как говорится.
Тут важно не перегнуть палку. Есть примеры, когда фичи наращиваются и наращиваются. Телефоны, например. Софт — это не просто средство получить желаемое, так обо всём что угодно можно сказать. Софт — это инструмент, как плоскогубцы. Или швейцарский нож. И нужно этот инструмент сделать удобным для человека, а также всегда помнить, для чего этот инструмент нужен, чтобы не наворотить ненужного.
Marwin
16.09.2017 13:57+2Многие компании измеряют продуктивность разработчика по количеству строк кода, или по скорости, грубо говоря, число сделанных фич за единицу времени, умноженное на их размер.
ну в этом нет ничего плохого… количество фич прямопропорционально соотносится с его трудочасами. А вот нужность этих фич — это забота архитектора/дизайнера и вообще заказчика, но никак не разработчика.
vsabadazh Автор
16.09.2017 14:00+1Я думаю, такой подход работает в случае с аутсорсом, когда проект делается в интересах одного заказчика, и оплата идет за «человекочасы», плюс и от заказчика есть понимание того, что надо сделать (в идеале — ТЗ).
В случае с продуктовой компанией, не всегда можно с ходу угадать запросы клиентов.Cryvage
17.09.2017 03:19В случае с продуктовой компанией, не всегда можно с ходу угадать запросы клиентов.
В том-то и дело, что зачастую понимание приходит в процессе. Причем не только к разработчику, но и к пользователю. Часто сталкивался с тем, что люди не могут сформулировать чего они хотят. В таких случаях надо просто реализовать некий функционал, и выставить его «на суд». Сразу появляются более конкретные замечания и предложения. При этом, в части касающейся программиста, опять всё упирается в скорость реализации фич. Пусть даже это будет не пять разных фич, пять переделок одной и той же фичи, всё равно, чем быстрее, тем лучше.
VolCh
17.09.2017 13:56Для рядового разработчика обычно особо нет разницы решает он бизнес-задачи внешнего заказчика или внутреннего, поскольку реально он решает технические задачи, поставленные своим непосредственным руководителем, обычно даже не зная должна новая фича увеличить доходы или уменьшить расходы.
Labunsky
16.09.2017 21:00но никак не разработчика
Эту фразу повторяют тут уже так часто и относительно такого количества всевозможных задач, что настало время спросить — а что вообще забота разработчика? Код и его качество? И все?Cryvage
17.09.2017 04:03+3А что ещё по вашему должно входить в обязанности разработчика? Разработчику дают некое ТЗ, ну или хотя бы на словах объясняют что требуется сделать. Он выполняет поставленную задачу. Результатом его работы является программный код. За что ещё он должен отвечать? В отдельных случаях он может внести какие-то свои предложения по технической части. Но говорить о том нужен ли какой-либо функционал или нет… Он может иметь своё мнение на этот счёт, и может высказать это мнение, но это уж точно не его обязанность. Точнее, это может быть его обязанностью, если это прописать в договоре. Тогда это будет его обязанность как сотрудника, но не как разработчика. Иными словами он уже будет не только лишь разработчиком, но и кем-то ещё. Например, консультантом.
Так-то в обязанности можно записать что угодно. Например, у нас на работе мы не только пишем код, но ещё и занимаемся техподдержкой, ездим на объекты, устанавливаем наше ПО, проводим обучение по работе с ним и т.д. Но это не отменяет того факта, что как разработчики мы отвечаем только за код. Остальные сферы ответственности, хоть и относятся к нам, к разработке отношения не имеют.Labunsky
17.09.2017 22:59+1Всегда считал, что разработчик от слова «разрабатывать», а не «код писать». Фичи и их нужность те же — вполне сфера разработки, как по мне
Просто нам нужна новая терминология, специально для энтерпрайза, где на каждый чих — своя должность :)
alexeykuzmin0
19.09.2017 18:27Мне кажется, хороший разработчик все же должен предложить изменения в предлагаемой к реализации фиче, если это при небольших изменениях в поведении кардинально удешевит разработку.
Cryvage
20.09.2017 03:39Ну лично для меня это как раз входит в утверждение:
В отдельных случаях он может внести какие-то свои предложения по технической части.
Потому как разработчик тут, прежде всего, за техническую часть говорит. Его волнует реализация, и он говорит с этой позиции. Он может поставить перед фактом, что сделать так как заявлено в ТЗ получится дорого, или долго и т.п. Может предложить альтернативу, опять же ссылаясь на плюсы с точки зрения реализации.
Целесообразность реализации функционала ставится под сомнение, основываясь на технических сложностях, а не на том, что этот функционал не нужен потребителю. Альтернатива предлагается не потому, что она лучше для потребителя, а потому что её реализовать проще, быстрее, дешевле и т.д.
Тут нет никакого выхода за рамки технической части.
VolCh
17.09.2017 13:45В общем случае да — эффективно реализовать функциональные (фичи) и нефункциональные (ресурсы) требования. Разработчики могут участвовать в выработке этих требований, но, как правило, решающего голоса не имеют, владеют продуктами другие люди.
Mordexay
16.09.2017 14:02полностью согласен! Но ведь разработчики нацелены получить прибыль, а не клиента… только грамотная мотивация разрабов на результат может принести действительно потрясающие плоды
vsabadazh Автор
16.09.2017 14:04+1всё так, но без клиента нет и прибыли. Вот тут интересно: можно выпустить продукт, и по метрикам вроде как всё ок, но упущенная выгода из-за плохого интерфейса может быть очень велика.
aosja
16.09.2017 14:40+3Спасибо за перевод. Конкретно статья — странная. Не то реклама чего-то, не то автор обломился написать что-то более емкое. Пардон, но капитанство ИМХО…
vsabadazh Автор
16.09.2017 16:29+1Конечно капитанство. Но, с другой стороны, взгляните на софт, которым мы пользуемся ежедневно. Мне кажется, этот капитан Очевидность должен заглянуть в примерно 80% контор, которые выпускают ПО, в том числе веб-сайты.
SirEdvin
16.09.2017 16:25-1Опять же таки, стоит учитывать, что есть разные типы софта. Есть софт вспомогательный, у которого как раз чем больше полезных фич, тем лучше. Например, IDE.
vsabadazh Автор
16.09.2017 16:27К IDE вопросов нет, но их ведь и используют не совсем простые юзеры?
SirEdvin
16.09.2017 16:29+1У них есть своя целевая аудитория. Если вам кажется, что программисты избранные и нужное им ПО отличается от тех, которые нужны обычным пользователям, то возьмите аудиоплееры. По факту, проигрывать музыку без глюков довольно легко, вот они и берут только дизайном + фичами.
michael_vostrikov
16.09.2017 19:22+1Цель плеера не столько проигрывать музыку, сколько управлять музыкой. Как и цель IDE управлять разработкой. В целом посылу статьи это не противоречит. Главное не фичи, а получение результата.
SirEdvin
18.09.2017 10:29Получение какого результата? Управление музыкой это не результат, а процесс.
veydlin
17.09.2017 01:41Я вот пытался найти плеер с сенсорным экраном чтобы быстро перематывать треки, т.к. листать кнопками плейлист в пару тысяч треков занятие не быстрое
Но я не нашел ничего простого, я совсем не хочу чтобы в плеере были игры, интернет, приложения, даже будильник с часами мне не нужен. Хочу запускать и видеть список треков, все. Вот где такое найти?4ainik
18.09.2017 13:26возможны два варианта:
1) написать самому
2) заказать разработку на фрилансе :)
Grox
16.09.2017 17:10Фичи IDE обычно сосредоточены, как раз в области сокращения шагов от задачи к решению.
Ckpyt
16.09.2017 20:43+1Это подход к менеджеру. Менеджер должен осознавать, что тот код, который он продает, никому не нужен. Потому что именно он получает требования от заказчика. Именно он работает с заказчиком.
UI дизайнер обязан знать что от его интерфейса зависит удобство пользователей.
Архитектору… такую идею можно доносить… Можно, но не надо. У него есть требования заказчика и он должен придумать как их реализовать, составить тз для прогеров и пронаблюдать, чтобы оно выполнилось в срок и правильным образом. В рамках его задач идея о нужности кода или услуги она как-то особо не всплывает.
И уж тем более эту идею нельзя доносить до рядового программера. Потому что он тогда начнет вредить: раз код не нужен, а нужен продукт, да еще как можно быстрее, то в жопу читаемые имена, в жопу комменты. Все равно, код не нужен, нужна услуга.hlebloika
17.09.2017 01:34+1«И уж тем более эту идею нельзя доносить до рядового программера. Потому что он тогда начнет вредить: раз код не нужен, а нужен продукт, да еще как можно быстрее, то в жопу читаемые имена, в жопу комменты.»
Вот ни разу в жизни не встречал таких разработчиков. Все понимали, что ценность имеет именно конечный продукт, и что комменты и читаемые имена нужны для того, чтобы в дальнейшем продукт было легче развивать и поддерживать.VolCh
17.09.2017 13:50Так продукт обычно ценности не имеет для пользователя. Имеет результат, который пользователь получает с помощью продукта, будь то увеличение доходов или уменьшение расходов для бизнес-пользователей или получения максимум удовольствия от игры для геймера.
phikus
16.09.2017 21:09+4Это же почти один в один повторение идеи "лучший интерфейс — это отсутствие интерфейса"
https://m.habrahabr.ru/post/156473/
maniacscientist
17.09.2017 09:57Опять пытаются раскрутить кнопку «Сделать 3.14здато». Не, таковые существуют, конечно, только это совершенно другой уровень разработки, с привлечением разных дорогостоящих специалистов по анализу. Тут же пытаются впарить, что обычные разработчики должны выдавать подобный результат. Эволюционируйте, черные, ночами не спите, акционеры не ждут! Фу такими быть
DjOnline
17.09.2017 11:09Я вижу дизайн хабра в очередной раз страдает. Метка «перевод» и url страницы перевода находятся на разных строках, что мешает глазу зацепиться за обе строки одновременно и сходу увидеть что это перевод. Ну и никто не мешает продублировать это снизу, как это было раньше.
lexore
17.09.2017 13:42И так, воспроизведем логику автора вместе с выводом.
Директор приказывает выпустить программный продукт.
Ответственный менеджер пишет ТЗ.
Продуктологи придумывают фичи.
Программисты пишут реализацию.
После выхода продукта, все понимают, что продукт — г**но.
Кто виноват? Программисты.
В остальном согласен — фичи нужно придумывать, исходя из потребностей клиента.
Поэтому мне так приятно быть сфере веб разработки — прототипы, a/b тесты, статистики, конверсии, анализ реакции пользователя, отбраковывание нерабочих вариантов.
А ещё сбор метрик, аналитика, воронки всякие… аж душа радуется.
Эту статью очень хочется показать авторам интерфейсов офисных пакетов.
Действительно ли людям нужны все кнопочки и галочки, которые там есть?
И действительно ли они распиханы в интуитивном порядке?
Кто-нибудь в начале 2000-х вообще проводил исследование, в котором бы люди говорили "О да, мы хотим новый ленточный интерфейс!".
Это пример, когда потребности клиента пытались угадать, не спрашивая самого клиента.
Вот здесь автор попал в точку.
AbstractGaze
17.09.2017 19:32Я не разработчик, но мне вот интересно. А писать хороший софт сейчас вообще выгодно?
Поясню.
Я чуть более 10 лет работаю в сапорте, поработал в разных фирмах от 4 компов, до несколько тысяч. Но, вот подход зачастую у директоров как минимум странный — они платят не за то что все работает, а за то когда сапорт работает, т.е когда бизнес стоит из-за поломки.
Например до сих пор есть фирма с ит отделом, зарплатный фонд, аренду и прочие затраты в % соотношении платят «отделы». % зависит от времени, которое сотрудник затратил на устранение проблемы. Т.е. чем дольше все не работало, тем больший % платит «отдел». Т.е. если у «отдела» месяц ничего не работало, они заплатят 99% заработной платы. А те у кого все работало — не заплатят ничего вообще.
Аналогично у нас есть некоторые аутсорсеры, которые не делают так чтобы работало, им это просто не выгодно, и еженедельные походы к клиентам, что нибудь «починить» это нормально.
Поэтому и возникает вопрос — а с софтом таких проблем нету? т.е. делать так, чтобы потом надо было постоянно обслуживать изначально? Заказчик понимает что ему нужно, или заказчик хочет чтобы просто выполнялась работа, а нужная она или нет не важно?
Мне кажется пока в бизнесе не поймут за что они платят, так и будут разные не понятки, которые будут использоваться в своих интересах (получении сугубо личной прибыли, а не качества).alexeykuzmin0
19.09.2017 18:33Я точно знаю, что есть крупные и хорошо зарабатывающие компании, которые очень заботятся о качестве кода. Правда, не уверен, хорошо они зарабатывают благодаря этому или вопреки, но тут уж никто вам не скажет
4ainik
18.09.2017 13:59Вообще ситуация не такая однозначная…
Если брать отдельного разработчика, к которому обратился заказчик, то да эта ситуация звучит абсурдно, т.к. для чего тогда клиенту заказывать такой глючный и не рабочий софт?!
Но с другой стороны, если вы работаете на большую контору, то такая ситуация вполне логична по нескольким причинам:
1) вы не один в компании, другие тоже должны работать..., а если вы написали софт, который работает все время, т.е. получается, что вам делать будет нечего, а уж суппорту и подавно, т.е. можно разгонять контору… в противном случае за что к примеру суппорту платить деньги?
2) в большой конторе разделение ролей и бюрократия и от момента обнаружения глюка, до момента его устранения может пройти довольно много времени. К примеру суппорт МТС обычно отводит на это пол года :)
Nakosika
Да, меня тоже удивляют некоторые компании, где эффективность оценивается количеством фич. Тупо механически. Никакого видения. И ведь успешные клломпалнии, не сказал бы что менеджмент тупой. Просто видения нет, нет понимания цели софта, и вот нанимаются тысячи программистов, которые пилят сотни тысяч фич вокруг десятка экранов которые реально интересны пользователю.
staticlab
Сейчас такая гонка идёт в области мобильных банк-клиентов: рейтинги выставляются за количество фич.
Stan_1
Бизнес-задачка: Вы — владелец компании по производству софта. У Вас — команда разработчиков под управлением директора по разработке/развитию/пр. Вы — замучены налогами, бухгалтерией, административной работой. Вопрос: как Вы сформулируете KPI для такого директора по разработке? Причем KPI, однозначно оцениваемые и Вами и директором, и зависящие только от него?
Я думаю — именно в этом корень проблем софта средних и больших компаний.
Nakosika
Это напоминает мне статью Пола Грэма о том, почему в Америке не производят красивые автомобили. Как оценить дизайн и работу дизайнера если у тебя нет вкуса?
Просто в этом есть замкнутый круг, и рано или поздно появится руководитель со вкусом, который выкинет всех нафиг с рынка. За примером ходить не нужно, такое случается постоянно — как Эппл кикнули всех производителей смартфонов, так и в других областях постепенно уродливые и перегруженные сайты вытесняются хоть и менее функциональными, но более простыми/приятными в использовании. Если бы в Гугле вовремя не спохватились и не замутили свой материал дизайн, так и остались бы компанией, которая делает софт для гиков и нищебродов.
Stan_1
И все-таки, возвращаясь к моему вопросу: какие бы Вы придумали KPI для наемного работника — директора по развитию, которые можно было бы через полгода померять, чтобы доказать ему (директору), что он не справился?
Nakosika
Количество новых клиентов, привлеченных его проектами? Сумма покупок новыми клиентами или новых продуктов старыми клиентами?
Директор по развитию у вас как главный маркетолог? Или главный по производству? Или он просто делает все то что должен делать генеральный, но так чтобы на него можно было свалить отсутствие улучшений? Что-то я сомневаюсь чтобы у Джобса был свой директор по развитию.
Stan_1
Новые клиенты, сумма покупок, и даже возврат клиентов — больше зависят от продажников (даже не от маркетологов). Директор по развитию скажет — продукт отличный, продажники у нас плохие. :) Я как раз сейчас такое в одной компании наблюдаю. Поверьте, уже полтора года спор — плохие продажники или плохой продукт — не решен. Опросы клиентов ничего не дают, и противоречивы. А у руководства нет оснований встать на ту, или иную сторону.
Директор по развитию в моем примере — скорее всего смесь тим-лидера и продуктолога, то есть человека, который должен, по классике, организовать производство, и при этом понимать — как сделать продукт с короткими сроками и дешевой себестоимостью, имеющий задел развития.
Не очень верю, что возможно надолго найти тим-лидера и маркетолога в одном лице. Если такие люди есть — они уходят в свой бизнес.
Итого, максимум что мы найдем — это очень классного тим-лидера (более обще — производственика), который должен взять идеи хозяина, сделать их быстро, и дешево. И вот что можно такому человеку поставить в KPI?
— Сроки
— Себестоимость
— Число новых фич
— Число исправлений старых багов
Пожалуй — все. Все остальное — не его заслуга, а заслуга команды: он должен делать быстро и дешево, маркетолог — формировать фон продукта и продумать его цену, продажник — найти ценой печени клиентов. И вряд ли вы поставите ему в KPI параметры продажников. Тогда не будут работать продажники. А так… как только Вы (ну… условный «вы») становитесь администратором — то начинаете инвестировать прежде всего в продажи (они приносят кеш для жизни фирмы), и закрываете глаза на то, что продажник говорит тим-лидеру: «слышь, командир, Петрович вчера по пьяни в бане три фичи заказал. Лажа, но мне нужно показать, что мы умеем под него прогибаться. Метнись, сделай через недельку».
Ну и все. Дальше — как уже в моем опыте, когда мне программист один (в личном проекте) не сделал состояния кнопок «мышь наведена» и «кнопка нажата», со словами — «ну так, а ты не просил в ТЗ». И я понимаю, что это нормально: задача была сделать с оговоренной ценой и в срок. Задачи думать — не было. :)
Поэтому есть две вариации: или собственник продолжает «тащить» продукт на себе, одновременно являесь продуктологом, маркетологом, продажником и производственником. Но тогда у него не будет масштабирования бизнеса никогда. Или он — администратор-руководитель, который наращивает масштабы ценой изменения подхода к разработке продукта от «творчества» к «ремеслу», падения качества ПО, и усиления службы продаж. Я вот другого не наблюдал :(
Касательно Эппл. Все правильно пишите — но других примеров почти нет. И полномочия Джобсу дали только в его второй «заход» в Apple, когда уже шли ко дну. Это — особая история.
Nakosika
Да, я к тому и веду, что собственник / генеральный должен тащить. А то норовят нанять сотрудников, которые якобы тащить будут. Способные люди один на тысячу, перепоручить бесконтрольно — считай слить направление. Поэтому генерал лично должен тащить и в продажах, и в производстве, и в дизайне, и в поддержке, и каждый день проходить по офису и спрашивать как дела, и тыкать раз в неделю продукт и проверять как работают фичи, и смотреть тексты заказываемой рекламы, и читать лично важные договоры, и проверять бухгалтерию с финдиректором чтобы деньги никуда не подевались и налоги были уплачены вовремя, и тд.
Очень модная теория что можно кого попало нанять и если ты хороший руководитель, то можно в отпуск уезжать и никто не заметит разницы. Полная брехня, в лучшем случае можно уехать только в период затишья, когда разогнанная тачанка несется по инерции. Малейший ухаб — и все летит в тар-тарары.
Дела делают только индивидуумы. Группа не способна на креатив и смелые решения, сколько не плати. Поэтому груз генерального директора особенно тяжел, и поэтому сотрудник, который сам может справляться с проблемами — большая удача, а не что-то само собой разумеющееся, как почему-то кажется простым сотрудникам.
Поэтому, да, генерал и в дизайне и в разработке и в развитии шарить обязан на уровне. Не до мельчайших подробностей конечно, но говно от конфеты отличать должен, и объяснить почему, а также уметь поговорить на эту тему с сотрудниками и порасспрашивать почему именно так а не как у конкурентов. И такой генерал, конечно же, легко увидит с продуктом косяк или с рекламой.
Stan_1
Бинго! Абсолютно точный вывод. Но в компании большой и мультипродуктовой — генеральный физически не сможет «тащить». Поэтому итог — закономерен, и практически единственно возможный. А именно — описанный в статье.
TimTowdy
Решение есть — каждый директор по развитию должен быть немного продажником, и наоборот. Если продажники говорят, что продать не получается, т.к. продукт плохой, то директор идет и сам продает. И своим примером показывает, что он прав.
Ну а продажники должны не тупо продавать, а пытаться выяснить какие у клиентов потребности и как стоит развивать продукт. Т.е. они отчасти делают работу того самого директора по развитию и должны доносить ему эту информацию. Если он с ними не согласен, и считает что фича, о которой они говорят — не нужна, то они в качестве теста продают эту несуществующую фичу, и доказывают, что потребность в ней есть.
В общем если у вас директор по развитию и продажники тычут пальцами друг в друга, то у вас беда. Они должны работать сообща. Если нет продаж, то однозначно виноваты обе стороны.
Stan_1
Я тоже за мир во всем мире. Но как-то не получается. :(
Скорее всего продаст. Но пример профессионала для «массовой машины продаж» — ни о чем, потому что продажники чаще обладают низкой квалификацией. Иначе — они были бы не продажники, а директора по развитию и директора по продажам.
«слышь, командир, Петрович вчера по пьяни в бане три фичи заказал. Лажа, но мне нужно показать, что мы умеем под него прогибаться. Метнись, сделай через недельку» :)
И я за мир во всем мире :)
Всех уволить? И потратить от полугода до года на набор новых? Тогда бизнес совсем остановиться. Или бонусы не заплатить? А как, если свои KPI все выполнили? Программисты написали код быстро и дешево и в ТОЧНОМ соответствии с ТЗ. А директор по развитию нарисовал Roadmap в ТОЧНОМ соответствии с пожеланиями продажников. А продажники говорят — продукт «г....».
Поэтому мой первый вопрос про KPI и был :)
TimTowdy
У вас, как я понял, выводится новый продукт на рынок. В такой ситуации мне кажется полезнее иметь стартапное мышление, а не корпоративное.
А в стартапе важнее всего мотивация, с которой, судя по описанию, у вашего директора по развитию большие проблемы. Он может быть классным специалистом, но ему пофиг на конечный результат.
Грубо говоря, если его спросить «что ты сделал для того чтоб у нас были продажи», он не имеет права ответить «а я тут причем, это работа продажников». На руководящие должности нужно ставить тех, кто берет на себя ответственность, а не тех, кто хорошо ищет виноватых. Рискну предположить, что вам будет выгоднее нанять более мотивированного директора, даже если он будет менее опытен чем текущий.
Stan_1
Он выводится в рамках большой корпорации, где все смежные службы даже не знают что такое стартап.
Он так не скажет. Если он не умен, то скажет: «я сделал лучши продукт, внедрил аджайл, сократил сроки работы, сделал все фичи по запросу продаж. Они плохо продают». Если умен, то «да, проблема. Где-то произошел сбой между нами и продажами. Нужно выстраивать вертикаль от продукта до клиента. Передайте мне службу продаж в прямое подчинение» :)
Мотивация закончиться ровно в момент подсчета бонуса на основе выполненного KPI. Особенно, если продажи докажут, что продукт плохой, и свои бонусы получат :)
И я оставлю за скобками, что «мотивированный» руководитель (то есть умеющий думать, и формировать события) в большую компанию идет только за тремя вещами:
— получить должность, как шаг в карьере
— сразу метить в этой корпорации на топовые позиции
— тупо напилить денег
и потом или вверх (в топ-менеджеры, желательно управляющих компаний), либо создавать свой бизнес, желательно «около» продукта, который был создан в рамках большой компании.
И не бывает у таких людей мотивации на хороший продукт. Или мне не повезло, и я таких не встречал :)
TimTowdy
На самом деле есть люди, которые хотят видеть результат от своей работы не только в виде суммы на личном счету. У них просто дискомфорт от того, что работа сделана, а результатов (продаж) нет. Даже если при этом зарплата исправно платится.
Но вы правы, в корпорациях они редко уживаются. Либо меняют систему, либо (значительно чаще) — уходят.
Stan_1
Видел таких людей. Но они, как правило, уходят в свой бизнес. И да — в корпорациях таким не ужиться. :(
andrew911
Кого кикнул Эппл?
Vkuvaev
Это график долей рынка, причем только сейчас анонсированы новые смартфоны Apple.
Есть ли график по прибыли? И еще, если привели одну картинку то и вторую, из того же отчета плиз. Два самых продаваемых смартфона в мире это IPhone7 и IPhone7 Plus. Apple, давно по доле рынка не лидер, к сожалению, не нашел где графики по прибыли, но они, обычно, снимают самые сливки.
pav5000
С определённой точки зрения Эппл как раз обратный пример. У них всё заточено под прибыль, а не удобство пользователя. Вспомните их несовместимые ни с чем разъёмы и специальные чипы в них, чтобы нельзя было купить альтернативный или искусственные препятствия, мешающие пользователю поставить тот софт, который ему нужен, а не тот, который хочет Эппл.
Vkuvaev
Тут все сильно связано, разумеется под прибыль, да аксессуары стОят. Но UX как его формируют в Apple весьма хорош. Есть где подтюнить, конкуренты не стоят, да и пользователи раскусили «фишку». Но, до IPhone, я пользовался смартфонами, это было очень убого. Вспомните именно этот момент, когда все были в сомнении и вдруг выстрелило, или с IPad? Ровно так же.
Думаю, люди несут деньги в Apple, потому, что верят, что компания позаботилась именно о UX. Как только этот фактор станет не true, вся империя разрушится. Я именно за это плачу, лично.
andrew911
Я думал под «кикнул остальных с рынка» и подразумевалась доля рынка, без дробления по моделям. По поводу новых смартфонов, предполагаю, что будет картинка аналогичная прошлым годам — в пике на какое-то время (месяц-два) немного обгонит Самсунг, но в целом видно, что они не первые точно.
Nakosika
Причем тут текущие продажи? Сейчас все могут делать более-менее нормальные смарты, даже Самсунг научился, хотя никто не верил…
Эппл кикнул винфоны и нокию когда выпустил первый айфон и просто сожрал рынок топовых смартов почти целиком.
Vkuvaev
Ага, вот занесло-то всех в дискуссии, под кикнуть подразумевалось дали толчок развитию:)
TimTowdy
Apple практически каждый квартал забирает не менее 80% всей прибыли на рынке смартфонов. А в некоторые, как бы смешно это не звучало, даже больше 100%.