Владелец продукта — это человек, который знает продукт как свои пять пальцев. Он составляет требования, управляет дорожной картой — словом, дает работу нам, разработчикам. И все это он делает, стараясь оградить нас от «бизнес-проблем» — что бы это ни значило.
Если вы владелец продукта, наверняка хмуритесь, читая эти строки, и не ожидаете ничего хорошего в дальнейшем. Однако не стоит так напрягаться! Несмотря на ироничный тон статьи, мы, разработчики, искренне ценим вас.
Просто некоторые ваши требования и поступки кажутся нам нелепыми. Не в смысле «невозможно работать в таких условиях», а скорее в смысле «невозможно не умилиться тем, что вы делаете».
В любом случае стоит обратить внимание на некоторые из ваших привычек. Вот пять самых неэффективных!
1. Сопровождение задания словами «это просто»
Давая нам поручение, вы обычно говорите что-то вроде «это должно быть очень просто». Именно так, заверяя нас в том, что справиться с работой довольно легко, вы одновременно спрашиваете, сможет ли ее выполнить кто-нибудь опытный. Абсолютно логично.
Некоторые идут дальше и сопровождают свою просьбу пожеланиями:
Намерения понятны. Вы пытаетесь снять напряжение, чтобы задание не казалось слишком трудным. А в качестве дополнительного аргумента используете слова «всего лишь» — явный признак желания «смягчить удар».
Но дело в том, что работа инженера всегда будет сопряжена с определенной сложностью. Она не станет проще от мягких внушений, а момент ее завершения невозможно предугадать никому.
Излишне заранее определять сложность задания или сроки его выполнения — вместо этого нужно четкое и краткое изложение требований.
2. Разработка дизайна проекта
Во время совещания по планированию, подгадав подходящий момент, вы представляете свой «шедевр», созданный в MS Paint. Вы говорите: «Я выполнил базовый макет, просто чтобы показать, что я имею в виду». В этот момент разработчики изо всех сил стараются скрыть досаду и смущение.
Проблема в том, что мы легко раскрываем вашу уловку. Мы понимаем, что «базовый макет» на самом деле является реальным, тщательно продуманным вами проектом, и вы надеетесь, что он будет создан точно по вашей спецификации. Представляя свое «произведение искусства», вы втайне надеетесь, чтобы кто-нибудь произнес пять одобрительных слов: «А ведь и правда неплохо!»
Но, к сожалению, этого не происходит. Наоборот, возникает неловкая ситуация, при которой некоторым из присутствующих требуется немало усилий, чтобы сдержать смех. Особенно неловко чувствуют себя опытные UX/UI-эксперты. Более того, некоторым из них трудно сдержать слезы.
Почему бы не оставить разработку дизайна специалистам? В итоге вы получите продукт безупречного вида, и произойдет это гораздо быстрее, чем ожидалось.
3. Предложения по написанию кода
Совещания по планированию — идеальная возможность обсуждения технических моментов в кругу профессионалов. Это безопасное пространство, где приветствуются любые идеи. Единственное правило — никаких глупых вопросов… в большинстве случаев.
Правда, у этого правила есть одно исключение. Речь идет о ситуации, когда разработчики пытаются разобраться в сложной проблеме, а владелец продукта с нулевым опытом проектной работы вклинивается в их разговор. Мягко говоря, это отвлекает и почти всегда принимает форму предложения по написанию кода.
Все начинается с прерывания обсуждения словами: «Простите, если я слишком упрощаю, но…». Затем, когда разработчики пытаются сохранить самообладание, тщетно стараясь удержать в голове нить рассуждений, он говорит очевидное: «А разве не проще написать так: «Если есть файлы-куки, показать модальное окно»?».
Подобные предложения, возможно, имели бы смысл в студенческой среде, но, как правило, неуместны в ходе экспертного обсуждения. Владельцу продукта следовало бы не вмешиваться в разговор специалистов, а предоставить им возможность подумать, обсудить проблему и разобраться в ней.
4. Поощрение плагиата
Владелец продукта не хочет, чтобы разработчики тратили драгоценное время на проектирование. По его мнению, это крайне неразумно. Он предпочел бы превратить нас в чемпионов по использованию Ctrl+C/Ctrl+V.
Он говорит что-то вроде: «Я уже видел, как это делала команда по привлечению пользователей, свяжу вас с ней, и вы сможете использовать ее код».
Конечно, зачем думать, если можно позаимствовать готовое решение? Что это? C#? Еще лучше! Этот язык точно будет работать в нашем приложении Node.js. Добавим его и запустим в работу!
Опять же, мы прекрасно понимаем подобный подход — было бы здорово воспользоваться преимуществами готового кода. Но вероятность того, что решение другой команды органично впишется в нашу кодовую базу, близка к нулю.
Худший вариант описываемой модели поведения: «Я видел нечто подобное в интернете — пришлю вам URL, чтобы вы могли скопировать код». Не хочется даже комментировать.
5. Недооценивание сложности работы
Оценка сложности проекта может выражаться по-разному. Одни разработчики скрупулезно разбивают пользовательский интерфейс на части, определяя, сколько дней потребуется на создание каждой части. Другие предпочитают измерять сложность выполнения проекта в неделях. Третьи используют указатели размеров одежды: S — от «Small» («маленький»), M — от «Medium» («средний»), L — от «Large» (большой).
Но нет ничего более раздражающего, чем сообщить о своих расчетах, а в ответ увидеть недоуменное выражение лица и услышать: «Но ведь это всего лишь базовая страница!»
Почему подобная реакция так оскорбительна? Потому что она может означать одно из двух: «Мне думается, что вы очень медлительны» или «Мне кажется, что вы лжете». Ни то, ни другое не является хорошим тоном.
В заключение приведу одну из самых поразительных реплик, которые мне пришлось услышать от владельца продукта. Много лет назад я создавал сайт для своего начальника, который уже подписал контракт на разработку макета. Он пришел ко мне через день после начала работы, и, конечно же, на тот момент смотреть было особо не на что. Начальник расстроился, потому что рассчитывал на большее. Я вежливо объяснил, что макет так быстро не делается. Тогда он сказал: «Разве вы не можете просто выполнить HTML?»
Если время имеет значение, дайте нам знать об этом заранее — особенно если речь идет о дедлайне. Мы постараемся сделать все, что в наших силах, возможно, даже откажемся от некоторых полезных функций. Но нет никакого смысла пытаться убедить нас, что все должно быть проще.
Возможно, хотя бы несколько строк вызвали у вас усмешку или заставили сказать: «Да, узнаю себя».
Читайте также:
- Психологические принципы для продуктового дизайнера
- Топ-10 самых используемых SaaS-продуктов с открытым исходным кодом
- Курс на продуктивность: 10 бесплатных инструментов и сайтов для разработчиков
Читайте нас в Telegram, VK и Дзен
Перевод статьи Daniel Yefet: 5 Highly Ineffective Habits of Product Owners
