Комментарии 64
Да, меня тоже удивляют некоторые компании, где эффективность оценивается количеством фич. Тупо механически. Никакого видения. И ведь успешные клломпалнии, не сказал бы что менеджмент тупой. Просто видения нет, нет понимания цели софта, и вот нанимаются тысячи программистов, которые пилят сотни тысяч фич вокруг десятка экранов которые реально интересны пользователю.
НЛО прилетело и опубликовало эту надпись здесь
Бизнес-задачка: Вы — владелец компании по производству софта. У Вас — команда разработчиков под управлением директора по разработке/развитию/пр. Вы — замучены налогами, бухгалтерией, административной работой. Вопрос: как Вы сформулируете KPI для такого директора по разработке? Причем KPI, однозначно оцениваемые и Вами и директором, и зависящие только от него?
Я думаю — именно в этом корень проблем софта средних и больших компаний.
Я думаю — именно в этом корень проблем софта средних и больших компаний.
Это напоминает мне статью Пола Грэма о том, почему в Америке не производят красивые автомобили. Как оценить дизайн и работу дизайнера если у тебя нет вкуса?
Просто в этом есть замкнутый круг, и рано или поздно появится руководитель со вкусом, который выкинет всех нафиг с рынка. За примером ходить не нужно, такое случается постоянно — как Эппл кикнули всех производителей смартфонов, так и в других областях постепенно уродливые и перегруженные сайты вытесняются хоть и менее функциональными, но более простыми/приятными в использовании. Если бы в Гугле вовремя не спохватились и не замутили свой материал дизайн, так и остались бы компанией, которая делает софт для гиков и нищебродов.
И все-таки, возвращаясь к моему вопросу: какие бы Вы придумали KPI для наемного работника — директора по развитию, которые можно было бы через полгода померять, чтобы доказать ему (директору), что он не справился?
Количество новых клиентов, привлеченных его проектами? Сумма покупок новыми клиентами или новых продуктов старыми клиентами?
Директор по развитию у вас как главный маркетолог? Или главный по производству? Или он просто делает все то что должен делать генеральный, но так чтобы на него можно было свалить отсутствие улучшений? Что-то я сомневаюсь чтобы у Джобса был свой директор по развитию.
Директор по развитию у вас как главный маркетолог? Или главный по производству? Или он просто делает все то что должен делать генеральный, но так чтобы на него можно было свалить отсутствие улучшений? Что-то я сомневаюсь чтобы у Джобса был свой директор по развитию.
Новые клиенты, сумма покупок, и даже возврат клиентов — больше зависят от продажников (даже не от маркетологов). Директор по развитию скажет — продукт отличный, продажники у нас плохие. :) Я как раз сейчас такое в одной компании наблюдаю. Поверьте, уже полтора года спор — плохие продажники или плохой продукт — не решен. Опросы клиентов ничего не дают, и противоречивы. А у руководства нет оснований встать на ту, или иную сторону.
Директор по развитию в моем примере — скорее всего смесь тим-лидера и продуктолога, то есть человека, который должен, по классике, организовать производство, и при этом понимать — как сделать продукт с короткими сроками и дешевой себестоимостью, имеющий задел развития.
Не очень верю, что возможно надолго найти тим-лидера и маркетолога в одном лице. Если такие люди есть — они уходят в свой бизнес.
Итого, максимум что мы найдем — это очень классного тим-лидера (более обще — производственика), который должен взять идеи хозяина, сделать их быстро, и дешево. И вот что можно такому человеку поставить в KPI?
— Сроки
— Себестоимость
— Число новых фич
— Число исправлений старых багов
Пожалуй — все. Все остальное — не его заслуга, а заслуга команды: он должен делать быстро и дешево, маркетолог — формировать фон продукта и продумать его цену, продажник — найти ценой печени клиентов. И вряд ли вы поставите ему в KPI параметры продажников. Тогда не будут работать продажники. А так… как только Вы (ну… условный «вы») становитесь администратором — то начинаете инвестировать прежде всего в продажи (они приносят кеш для жизни фирмы), и закрываете глаза на то, что продажник говорит тим-лидеру: «слышь, командир, Петрович вчера по пьяни в бане три фичи заказал. Лажа, но мне нужно показать, что мы умеем под него прогибаться. Метнись, сделай через недельку».
Ну и все. Дальше — как уже в моем опыте, когда мне программист один (в личном проекте) не сделал состояния кнопок «мышь наведена» и «кнопка нажата», со словами — «ну так, а ты не просил в ТЗ». И я понимаю, что это нормально: задача была сделать с оговоренной ценой и в срок. Задачи думать — не было. :)
Поэтому есть две вариации: или собственник продолжает «тащить» продукт на себе, одновременно являесь продуктологом, маркетологом, продажником и производственником. Но тогда у него не будет масштабирования бизнеса никогда. Или он — администратор-руководитель, который наращивает масштабы ценой изменения подхода к разработке продукта от «творчества» к «ремеслу», падения качества ПО, и усиления службы продаж. Я вот другого не наблюдал :(
Касательно Эппл. Все правильно пишите — но других примеров почти нет. И полномочия Джобсу дали только в его второй «заход» в Apple, когда уже шли ко дну. Это — особая история.
Директор по развитию в моем примере — скорее всего смесь тим-лидера и продуктолога, то есть человека, который должен, по классике, организовать производство, и при этом понимать — как сделать продукт с короткими сроками и дешевой себестоимостью, имеющий задел развития.
Не очень верю, что возможно надолго найти тим-лидера и маркетолога в одном лице. Если такие люди есть — они уходят в свой бизнес.
Итого, максимум что мы найдем — это очень классного тим-лидера (более обще — производственика), который должен взять идеи хозяина, сделать их быстро, и дешево. И вот что можно такому человеку поставить в KPI?
— Сроки
— Себестоимость
— Число новых фич
— Число исправлений старых багов
Пожалуй — все. Все остальное — не его заслуга, а заслуга команды: он должен делать быстро и дешево, маркетолог — формировать фон продукта и продумать его цену, продажник — найти ценой печени клиентов. И вряд ли вы поставите ему в KPI параметры продажников. Тогда не будут работать продажники. А так… как только Вы (ну… условный «вы») становитесь администратором — то начинаете инвестировать прежде всего в продажи (они приносят кеш для жизни фирмы), и закрываете глаза на то, что продажник говорит тим-лидеру: «слышь, командир, Петрович вчера по пьяни в бане три фичи заказал. Лажа, но мне нужно показать, что мы умеем под него прогибаться. Метнись, сделай через недельку».
Ну и все. Дальше — как уже в моем опыте, когда мне программист один (в личном проекте) не сделал состояния кнопок «мышь наведена» и «кнопка нажата», со словами — «ну так, а ты не просил в ТЗ». И я понимаю, что это нормально: задача была сделать с оговоренной ценой и в срок. Задачи думать — не было. :)
Поэтому есть две вариации: или собственник продолжает «тащить» продукт на себе, одновременно являесь продуктологом, маркетологом, продажником и производственником. Но тогда у него не будет масштабирования бизнеса никогда. Или он — администратор-руководитель, который наращивает масштабы ценой изменения подхода к разработке продукта от «творчества» к «ремеслу», падения качества ПО, и усиления службы продаж. Я вот другого не наблюдал :(
Касательно Эппл. Все правильно пишите — но других примеров почти нет. И полномочия Джобсу дали только в его второй «заход» в Apple, когда уже шли ко дну. Это — особая история.
Да, я к тому и веду, что собственник / генеральный должен тащить. А то норовят нанять сотрудников, которые якобы тащить будут. Способные люди один на тысячу, перепоручить бесконтрольно — считай слить направление. Поэтому генерал лично должен тащить и в продажах, и в производстве, и в дизайне, и в поддержке, и каждый день проходить по офису и спрашивать как дела, и тыкать раз в неделю продукт и проверять как работают фичи, и смотреть тексты заказываемой рекламы, и читать лично важные договоры, и проверять бухгалтерию с финдиректором чтобы деньги никуда не подевались и налоги были уплачены вовремя, и тд.
Очень модная теория что можно кого попало нанять и если ты хороший руководитель, то можно в отпуск уезжать и никто не заметит разницы. Полная брехня, в лучшем случае можно уехать только в период затишья, когда разогнанная тачанка несется по инерции. Малейший ухаб — и все летит в тар-тарары.
Дела делают только индивидуумы. Группа не способна на креатив и смелые решения, сколько не плати. Поэтому груз генерального директора особенно тяжел, и поэтому сотрудник, который сам может справляться с проблемами — большая удача, а не что-то само собой разумеющееся, как почему-то кажется простым сотрудникам.
Поэтому, да, генерал и в дизайне и в разработке и в развитии шарить обязан на уровне. Не до мельчайших подробностей конечно, но говно от конфеты отличать должен, и объяснить почему, а также уметь поговорить на эту тему с сотрудниками и порасспрашивать почему именно так а не как у конкурентов. И такой генерал, конечно же, легко увидит с продуктом косяк или с рекламой.
Очень модная теория что можно кого попало нанять и если ты хороший руководитель, то можно в отпуск уезжать и никто не заметит разницы. Полная брехня, в лучшем случае можно уехать только в период затишья, когда разогнанная тачанка несется по инерции. Малейший ухаб — и все летит в тар-тарары.
Дела делают только индивидуумы. Группа не способна на креатив и смелые решения, сколько не плати. Поэтому груз генерального директора особенно тяжел, и поэтому сотрудник, который сам может справляться с проблемами — большая удача, а не что-то само собой разумеющееся, как почему-то кажется простым сотрудникам.
Поэтому, да, генерал и в дизайне и в разработке и в развитии шарить обязан на уровне. Не до мельчайших подробностей конечно, но говно от конфеты отличать должен, и объяснить почему, а также уметь поговорить на эту тему с сотрудниками и порасспрашивать почему именно так а не как у конкурентов. И такой генерал, конечно же, легко увидит с продуктом косяк или с рекламой.
Дела делают только индивидуумы. Группа не способна на креатив и смелые решения, сколько не плати.
Бинго! Абсолютно точный вывод. Но в компании большой и мультипродуктовой — генеральный физически не сможет «тащить». Поэтому итог — закономерен, и практически единственно возможный. А именно — описанный в статье.
уже полтора года спор — плохие продажники или плохой продукт — не решен. Опросы клиентов ничего не дают, и противоречивыТакая проблема возникает из-за изолированности отделов, когда каждый тупо делает свою работу, игнорируя остальных. В итоге в неудачах все винят друг друга, а успех конечно же приписывают себе.
Решение есть — каждый директор по развитию должен быть немного продажником, и наоборот. Если продажники говорят, что продать не получается, т.к. продукт плохой, то директор идет и сам продает. И своим примером показывает, что он прав.
Ну а продажники должны не тупо продавать, а пытаться выяснить какие у клиентов потребности и как стоит развивать продукт. Т.е. они отчасти делают работу того самого директора по развитию и должны доносить ему эту информацию. Если он с ними не согласен, и считает что фича, о которой они говорят — не нужна, то они в качестве теста продают эту несуществующую фичу, и доказывают, что потребность в ней есть.
В общем если у вас директор по развитию и продажники тычут пальцами друг в друга, то у вас беда. Они должны работать сообща. Если нет продаж, то однозначно виноваты обе стороны.
Такая проблема возникает из-за изолированности отделов, когда каждый тупо делает свою работу, игнорируя остальных
Я тоже за мир во всем мире. Но как-то не получается. :(
Если продажники говорят, что продать не получается, т.к. продукт плохой, то директор идет и сам продает. И своим примером показывает, что он прав.
Скорее всего продаст. Но пример профессионала для «массовой машины продаж» — ни о чем, потому что продажники чаще обладают низкой квалификацией. Иначе — они были бы не продажники, а директора по развитию и директора по продажам.
Ну а продажники должны не тупо продавать, а пытаться выяснить какие у клиентов потребности и как стоит развивать продукт.
«слышь, командир, Петрович вчера по пьяни в бане три фичи заказал. Лажа, но мне нужно показать, что мы умеем под него прогибаться. Метнись, сделай через недельку» :)
В общем если у вас директор по развитию и продажники тычут пальцами друг в друга, то у вас беда. Они должны работать сообща.
И я за мир во всем мире :)
Если нет продаж, то однозначно виноваты обе стороны.
Всех уволить? И потратить от полугода до года на набор новых? Тогда бизнес совсем остановиться. Или бонусы не заплатить? А как, если свои KPI все выполнили? Программисты написали код быстро и дешево и в ТОЧНОМ соответствии с ТЗ. А директор по развитию нарисовал Roadmap в ТОЧНОМ соответствии с пожеланиями продажников. А продажники говорят — продукт «г....».
Поэтому мой первый вопрос про KPI и был :)
Поэтому мой первый вопрос про KPI и был :)Вы ведь запросили что-то нереальное: KPI директора (от слова direct), зависящее только от него. Результат работы директора по определению связан с другими людьми. Попробуйте померять работу снайпера, не смотря на мишени. Можно долго рассуждать как красиво он держит винтовку, и считать сколько он сделал выстрелов, но о результатах его работы это не скажет ничего.
У вас, как я понял, выводится новый продукт на рынок. В такой ситуации мне кажется полезнее иметь стартапное мышление, а не корпоративное.
А в стартапе важнее всего мотивация, с которой, судя по описанию, у вашего директора по развитию большие проблемы. Он может быть классным специалистом, но ему пофиг на конечный результат.
Грубо говоря, если его спросить «что ты сделал для того чтоб у нас были продажи», он не имеет права ответить «а я тут причем, это работа продажников». На руководящие должности нужно ставить тех, кто берет на себя ответственность, а не тех, кто хорошо ищет виноватых. Рискну предположить, что вам будет выгоднее нанять более мотивированного директора, даже если он будет менее опытен чем текущий.
У вас, как я понял, выводится новый продукт на рынок. В такой ситуации мне кажется полезнее иметь стартапное мышление, а не корпоративное.
Он выводится в рамках большой корпорации, где все смежные службы даже не знают что такое стартап.
Грубо говоря, если его спросить «что ты сделал для того чтоб у нас были продажи», он не имеет права ответить «а я тут причем, это работа продажников»
Он так не скажет. Если он не умен, то скажет: «я сделал лучши продукт, внедрил аджайл, сократил сроки работы, сделал все фичи по запросу продаж. Они плохо продают». Если умен, то «да, проблема. Где-то произошел сбой между нами и продажами. Нужно выстраивать вертикаль от продукта до клиента. Передайте мне службу продаж в прямое подчинение» :)
вам будет выгоднее нанять более мотивированного директора
Мотивация закончиться ровно в момент подсчета бонуса на основе выполненного KPI. Особенно, если продажи докажут, что продукт плохой, и свои бонусы получат :)
И я оставлю за скобками, что «мотивированный» руководитель (то есть умеющий думать, и формировать события) в большую компанию идет только за тремя вещами:
— получить должность, как шаг в карьере
— сразу метить в этой корпорации на топовые позиции
— тупо напилить денег
и потом или вверх (в топ-менеджеры, желательно управляющих компаний), либо создавать свой бизнес, желательно «около» продукта, который был создан в рамках большой компании.
И не бывает у таких людей мотивации на хороший продукт. Или мне не повезло, и я таких не встречал :)
На самом деле есть люди, которые хотят видеть результат от своей работы не только в виде суммы на личном счету. У них просто дискомфорт от того, что работа сделана, а результатов (продаж) нет. Даже если при этом зарплата исправно платится.
Но вы правы, в корпорациях они редко уживаются. Либо меняют систему, либо (значительно чаще) — уходят.
Но вы правы, в корпорациях они редко уживаются. Либо меняют систему, либо (значительно чаще) — уходят.
На самом деле есть люди, которые хотят видеть результат от своей работы не только в виде суммы на личном счету. У них просто дискомфорт от того, что работа сделана, а результатов (продаж) нет. Даже если при этом зарплата исправно платится.
Видел таких людей. Но они, как правило, уходят в свой бизнес. И да — в корпорациях таким не ужиться. :(
Над директором есть владельцы компании. Они и могут KPI для него выставить.
Кого кикнул Эппл?
Это график долей рынка, причем только сейчас анонсированы новые смартфоны Apple.
Есть ли график по прибыли? И еще, если привели одну картинку то и вторую, из того же отчета плиз. Два самых продаваемых смартфона в мире это IPhone7 и IPhone7 Plus. Apple, давно по доле рынка не лидер, к сожалению, не нашел где графики по прибыли, но они, обычно, снимают самые сливки.
Есть ли график по прибыли? И еще, если привели одну картинку то и вторую, из того же отчета плиз. Два самых продаваемых смартфона в мире это IPhone7 и IPhone7 Plus. Apple, давно по доле рынка не лидер, к сожалению, не нашел где графики по прибыли, но они, обычно, снимают самые сливки.
С определённой точки зрения Эппл как раз обратный пример. У них всё заточено под прибыль, а не удобство пользователя. Вспомните их несовместимые ни с чем разъёмы и специальные чипы в них, чтобы нельзя было купить альтернативный или искусственные препятствия, мешающие пользователю поставить тот софт, который ему нужен, а не тот, который хочет Эппл.
Тут все сильно связано, разумеется под прибыль, да аксессуары стОят. Но UX как его формируют в Apple весьма хорош. Есть где подтюнить, конкуренты не стоят, да и пользователи раскусили «фишку». Но, до IPhone, я пользовался смартфонами, это было очень убого. Вспомните именно этот момент, когда все были в сомнении и вдруг выстрелило, или с IPad? Ровно так же.
Думаю, люди несут деньги в Apple, потому, что верят, что компания позаботилась именно о UX. Как только этот фактор станет не true, вся империя разрушится. Я именно за это плачу, лично.
Думаю, люди несут деньги в Apple, потому, что верят, что компания позаботилась именно о UX. Как только этот фактор станет не true, вся империя разрушится. Я именно за это плачу, лично.
Я думал под «кикнул остальных с рынка» и подразумевалась доля рынка, без дробления по моделям. По поводу новых смартфонов, предполагаю, что будет картинка аналогичная прошлым годам — в пике на какое-то время (месяц-два) немного обгонит Самсунг, но в целом видно, что они не первые точно.
Причем тут текущие продажи? Сейчас все могут делать более-менее нормальные смарты, даже Самсунг научился, хотя никто не верил…
Эппл кикнул винфоны и нокию когда выпустил первый айфон и просто сожрал рынок топовых смартов почти целиком.
Эппл кикнул винфоны и нокию когда выпустил первый айфон и просто сожрал рынок топовых смартов почти целиком.
Кого кикнул Эппл?Всех. Абсолютно всех. Ваш график красивый, но бесполезный.
Apple практически каждый квартал забирает не менее 80% всей прибыли на рынке смартфонов. А в некоторые, как бы смешно это не звучало, даже больше 100%.
Старая как мир истина, которая обсасывается в различных изложениях и трактовках ооочень давно. «Лучший интерфейс — отсутствие интерфейса», как говорится.
Тут важно не перегнуть палку. Есть примеры, когда фичи наращиваются и наращиваются. Телефоны, например. Софт — это не просто средство получить желаемое, так обо всём что угодно можно сказать. Софт — это инструмент, как плоскогубцы. Или швейцарский нож. И нужно этот инструмент сделать удобным для человека, а также всегда помнить, для чего этот инструмент нужен, чтобы не наворотить ненужного.
Тут важно не перегнуть палку. Есть примеры, когда фичи наращиваются и наращиваются. Телефоны, например. Софт — это не просто средство получить желаемое, так обо всём что угодно можно сказать. Софт — это инструмент, как плоскогубцы. Или швейцарский нож. И нужно этот инструмент сделать удобным для человека, а также всегда помнить, для чего этот инструмент нужен, чтобы не наворотить ненужного.
Многие компании измеряют продуктивность разработчика по количеству строк кода, или по скорости, грубо говоря, число сделанных фич за единицу времени, умноженное на их размер.
ну в этом нет ничего плохого… количество фич прямопропорционально соотносится с его трудочасами. А вот нужность этих фич — это забота архитектора/дизайнера и вообще заказчика, но никак не разработчика.
Я думаю, такой подход работает в случае с аутсорсом, когда проект делается в интересах одного заказчика, и оплата идет за «человекочасы», плюс и от заказчика есть понимание того, что надо сделать (в идеале — ТЗ).
В случае с продуктовой компанией, не всегда можно с ходу угадать запросы клиентов.
В случае с продуктовой компанией, не всегда можно с ходу угадать запросы клиентов.
В случае с продуктовой компанией, не всегда можно с ходу угадать запросы клиентов.
В том-то и дело, что зачастую понимание приходит в процессе. Причем не только к разработчику, но и к пользователю. Часто сталкивался с тем, что люди не могут сформулировать чего они хотят. В таких случаях надо просто реализовать некий функционал, и выставить его «на суд». Сразу появляются более конкретные замечания и предложения. При этом, в части касающейся программиста, опять всё упирается в скорость реализации фич. Пусть даже это будет не пять разных фич, пять переделок одной и той же фичи, всё равно, чем быстрее, тем лучше.
Для рядового разработчика обычно особо нет разницы решает он бизнес-задачи внешнего заказчика или внутреннего, поскольку реально он решает технические задачи, поставленные своим непосредственным руководителем, обычно даже не зная должна новая фича увеличить доходы или уменьшить расходы.
но никак не разработчикаЭту фразу повторяют тут уже так часто и относительно такого количества всевозможных задач, что настало время спросить — а что вообще забота разработчика? Код и его качество? И все?
А что ещё по вашему должно входить в обязанности разработчика? Разработчику дают некое ТЗ, ну или хотя бы на словах объясняют что требуется сделать. Он выполняет поставленную задачу. Результатом его работы является программный код. За что ещё он должен отвечать? В отдельных случаях он может внести какие-то свои предложения по технической части. Но говорить о том нужен ли какой-либо функционал или нет… Он может иметь своё мнение на этот счёт, и может высказать это мнение, но это уж точно не его обязанность. Точнее, это может быть его обязанностью, если это прописать в договоре. Тогда это будет его обязанность как сотрудника, но не как разработчика. Иными словами он уже будет не только лишь разработчиком, но и кем-то ещё. Например, консультантом.
Так-то в обязанности можно записать что угодно. Например, у нас на работе мы не только пишем код, но ещё и занимаемся техподдержкой, ездим на объекты, устанавливаем наше ПО, проводим обучение по работе с ним и т.д. Но это не отменяет того факта, что как разработчики мы отвечаем только за код. Остальные сферы ответственности, хоть и относятся к нам, к разработке отношения не имеют.
Так-то в обязанности можно записать что угодно. Например, у нас на работе мы не только пишем код, но ещё и занимаемся техподдержкой, ездим на объекты, устанавливаем наше ПО, проводим обучение по работе с ним и т.д. Но это не отменяет того факта, что как разработчики мы отвечаем только за код. Остальные сферы ответственности, хоть и относятся к нам, к разработке отношения не имеют.
Всегда считал, что разработчик от слова «разрабатывать», а не «код писать». Фичи и их нужность те же — вполне сфера разработки, как по мне
Просто нам нужна новая терминология, специально для энтерпрайза, где на каждый чих — своя должность :)
Просто нам нужна новая терминология, специально для энтерпрайза, где на каждый чих — своя должность :)
Мне кажется, хороший разработчик все же должен предложить изменения в предлагаемой к реализации фиче, если это при небольших изменениях в поведении кардинально удешевит разработку.
Ну лично для меня это как раз входит в утверждение:
Потому как разработчик тут, прежде всего, за техническую часть говорит. Его волнует реализация, и он говорит с этой позиции. Он может поставить перед фактом, что сделать так как заявлено в ТЗ получится дорого, или долго и т.п. Может предложить альтернативу, опять же ссылаясь на плюсы с точки зрения реализации.
Целесообразность реализации функционала ставится под сомнение, основываясь на технических сложностях, а не на том, что этот функционал не нужен потребителю. Альтернатива предлагается не потому, что она лучше для потребителя, а потому что её реализовать проще, быстрее, дешевле и т.д.
Тут нет никакого выхода за рамки технической части.
В отдельных случаях он может внести какие-то свои предложения по технической части.
Потому как разработчик тут, прежде всего, за техническую часть говорит. Его волнует реализация, и он говорит с этой позиции. Он может поставить перед фактом, что сделать так как заявлено в ТЗ получится дорого, или долго и т.п. Может предложить альтернативу, опять же ссылаясь на плюсы с точки зрения реализации.
Целесообразность реализации функционала ставится под сомнение, основываясь на технических сложностях, а не на том, что этот функционал не нужен потребителю. Альтернатива предлагается не потому, что она лучше для потребителя, а потому что её реализовать проще, быстрее, дешевле и т.д.
Тут нет никакого выхода за рамки технической части.
В общем случае да — эффективно реализовать функциональные (фичи) и нефункциональные (ресурсы) требования. Разработчики могут участвовать в выработке этих требований, но, как правило, решающего голоса не имеют, владеют продуктами другие люди.
полностью согласен! Но ведь разработчики нацелены получить прибыль, а не клиента… только грамотная мотивация разрабов на результат может принести действительно потрясающие плоды
Спасибо за перевод. Конкретно статья — странная. Не то реклама чего-то, не то автор обломился написать что-то более емкое. Пардон, но капитанство ИМХО…
Опять же таки, стоит учитывать, что есть разные типы софта. Есть софт вспомогательный, у которого как раз чем больше полезных фич, тем лучше. Например, IDE.
К IDE вопросов нет, но их ведь и используют не совсем простые юзеры?
У них есть своя целевая аудитория. Если вам кажется, что программисты избранные и нужное им ПО отличается от тех, которые нужны обычным пользователям, то возьмите аудиоплееры. По факту, проигрывать музыку без глюков довольно легко, вот они и берут только дизайном + фичами.
Имеете ввиду софт или плееры как устройства?
Цель плеера не столько проигрывать музыку, сколько управлять музыкой. Как и цель IDE управлять разработкой. В целом посылу статьи это не противоречит. Главное не фичи, а получение результата.
Я вот пытался найти плеер с сенсорным экраном чтобы быстро перематывать треки, т.к. листать кнопками плейлист в пару тысяч треков занятие не быстрое
Но я не нашел ничего простого, я совсем не хочу чтобы в плеере были игры, интернет, приложения, даже будильник с часами мне не нужен. Хочу запускать и видеть список треков, все. Вот где такое найти?
Но я не нашел ничего простого, я совсем не хочу чтобы в плеере были игры, интернет, приложения, даже будильник с часами мне не нужен. Хочу запускать и видеть список треков, все. Вот где такое найти?
Фичи IDE обычно сосредоточены, как раз в области сокращения шагов от задачи к решению.
Это подход к менеджеру. Менеджер должен осознавать, что тот код, который он продает, никому не нужен. Потому что именно он получает требования от заказчика. Именно он работает с заказчиком.
UI дизайнер обязан знать что от его интерфейса зависит удобство пользователей.
Архитектору… такую идею можно доносить… Можно, но не надо. У него есть требования заказчика и он должен придумать как их реализовать, составить тз для прогеров и пронаблюдать, чтобы оно выполнилось в срок и правильным образом. В рамках его задач идея о нужности кода или услуги она как-то особо не всплывает.
И уж тем более эту идею нельзя доносить до рядового программера. Потому что он тогда начнет вредить: раз код не нужен, а нужен продукт, да еще как можно быстрее, то в жопу читаемые имена, в жопу комменты. Все равно, код не нужен, нужна услуга.
UI дизайнер обязан знать что от его интерфейса зависит удобство пользователей.
Архитектору… такую идею можно доносить… Можно, но не надо. У него есть требования заказчика и он должен придумать как их реализовать, составить тз для прогеров и пронаблюдать, чтобы оно выполнилось в срок и правильным образом. В рамках его задач идея о нужности кода или услуги она как-то особо не всплывает.
И уж тем более эту идею нельзя доносить до рядового программера. Потому что он тогда начнет вредить: раз код не нужен, а нужен продукт, да еще как можно быстрее, то в жопу читаемые имена, в жопу комменты. Все равно, код не нужен, нужна услуга.
«И уж тем более эту идею нельзя доносить до рядового программера. Потому что он тогда начнет вредить: раз код не нужен, а нужен продукт, да еще как можно быстрее, то в жопу читаемые имена, в жопу комменты.»
Вот ни разу в жизни не встречал таких разработчиков. Все понимали, что ценность имеет именно конечный продукт, и что комменты и читаемые имена нужны для того, чтобы в дальнейшем продукт было легче развивать и поддерживать.
Вот ни разу в жизни не встречал таких разработчиков. Все понимали, что ценность имеет именно конечный продукт, и что комменты и читаемые имена нужны для того, чтобы в дальнейшем продукт было легче развивать и поддерживать.
Это же почти один в один повторение идеи "лучший интерфейс — это отсутствие интерфейса"
https://m.habrahabr.ru/post/156473/
Опять пытаются раскрутить кнопку «Сделать 3.14здато». Не, таковые существуют, конечно, только это совершенно другой уровень разработки, с привлечением разных дорогостоящих специалистов по анализу. Тут же пытаются впарить, что обычные разработчики должны выдавать подобный результат. Эволюционируйте, черные, ночами не спите, акционеры не ждут! Фу такими быть
Я вижу дизайн хабра в очередной раз страдает. Метка «перевод» и url страницы перевода находятся на разных строках, что мешает глазу зацепиться за обе строки одновременно и сходу увидеть что это перевод. Ну и никто не мешает продублировать это снизу, как это было раньше.
И так, воспроизведем логику автора вместе с выводом.
Директор приказывает выпустить программный продукт.
Ответственный менеджер пишет ТЗ.
Продуктологи придумывают фичи.
Программисты пишут реализацию.
После выхода продукта, все понимают, что продукт — г**но.
Кто виноват? Программисты.
В остальном согласен — фичи нужно придумывать, исходя из потребностей клиента.
Поэтому мне так приятно быть сфере веб разработки — прототипы, a/b тесты, статистики, конверсии, анализ реакции пользователя, отбраковывание нерабочих вариантов.
А ещё сбор метрик, аналитика, воронки всякие… аж душа радуется.
Эту статью очень хочется показать авторам интерфейсов офисных пакетов.
Действительно ли людям нужны все кнопочки и галочки, которые там есть?
И действительно ли они распиханы в интуитивном порядке?
Кто-нибудь в начале 2000-х вообще проводил исследование, в котором бы люди говорили "О да, мы хотим новый ленточный интерфейс!".
Это пример, когда потребности клиента пытались угадать, не спрашивая самого клиента.
Вот здесь автор попал в точку.
НЛО прилетело и опубликовало эту надпись здесь
Элияху Голдрат "Цель 3".
Вообще ситуация не такая однозначная…
Если брать отдельного разработчика, к которому обратился заказчик, то да эта ситуация звучит абсурдно, т.к. для чего тогда клиенту заказывать такой глючный и не рабочий софт?!
Но с другой стороны, если вы работаете на большую контору, то такая ситуация вполне логична по нескольким причинам:
1) вы не один в компании, другие тоже должны работать..., а если вы написали софт, который работает все время, т.е. получается, что вам делать будет нечего, а уж суппорту и подавно, т.е. можно разгонять контору… в противном случае за что к примеру суппорту платить деньги?
2) в большой конторе разделение ролей и бюрократия и от момента обнаружения глюка, до момента его устранения может пройти довольно много времени. К примеру суппорт МТС обычно отводит на это пол года :)
Если брать отдельного разработчика, к которому обратился заказчик, то да эта ситуация звучит абсурдно, т.к. для чего тогда клиенту заказывать такой глючный и не рабочий софт?!
Но с другой стороны, если вы работаете на большую контору, то такая ситуация вполне логична по нескольким причинам:
1) вы не один в компании, другие тоже должны работать..., а если вы написали софт, который работает все время, т.е. получается, что вам делать будет нечего, а уж суппорту и подавно, т.е. можно разгонять контору… в противном случае за что к примеру суппорту платить деньги?
2) в большой конторе разделение ролей и бюрократия и от момента обнаружения глюка, до момента его устранения может пройти довольно много времени. К примеру суппорт МТС обычно отводит на это пол года :)
статья похожа на краткое изложение книжек Алана Купера =)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Твой софт никому не нужен. Или почему разработка ПО требует свежего подхода