Войти в систему
Войти с помощью соц. сетей:
В большинстве случаев, проанализировав новые идеи продукта, инженеры-программисты скажут, что у них нет особых причин беспокоиться об имеющихся технических возможностях. Ведь они, скорее всего, уже создавали нечто подобное много раз. Однако в нескольких ситуациях существует значительный риск технической реализуемости. Их разработчики довольно часто выявляют в связи с решением проблемы, над которой работают. Чаще всего причины для беспокойства связаны:
Для устранения этих типов рисков используется следующая методика: один или несколько инженеров-программистов создают прототип для тестирования реализуемости. Обычно это делает программист, поскольку, как правило, это код — в отличие от большинства других прототипов, которые создаются с помощью специализированных инструментов, чаще всего предназначенных для использования дизайнерами продукта. До коммерчески поставляемого продукта такому прототипу еще далеко, поэтому необходимо написать такой код, который позволит снизить этот риск. И, как правило, это лишь малая толика работы, которую придется сделать, чтобы получить потенциально выгодный с коммерческой точки зрения продукт. К тому же в большинстве случаев прототип для тестирования реализуемости представляет собой технологическую программу, временно используемую при разработке программного обеспечения, так что результат часто бывает быстрым и довольно «грязным», но это нормально. Предположительно его будет достаточно для сбора данных, чтобы, например, продемонстрировать, что производительность, скорее всего, будет приемлемой — либо неприемлемой. Пользовательский интерфейс, механизмы обработки ошибок и любая типичная работа по коммерческому внедрению продукта тут обычно не нужны.
По моему опыту, на создание прототипа для тестирования реализуемости уходит не более двух дней. Но если вы работаете над сложными новыми технологиями, скажем над новым подходом с использованием технологии машинного обучения, то для создания такого прототипа понадобится больше времени. Сколько, оценивают инженеры-программисты. А вот будет ли команда этим заниматься, зависит от менеджера продукта: он решает, стоит ли продолжать работу над идеей. Он может сказать, что другие подходы к решению проблемы не чреваты риском реализуемости, и предпочтет отказаться от этой идеи.
Хотя созданием прототипа для тестирования этого вида риска обычно занимаются инженеры-программисты, эту работу относят к этапу исследования продукта, а не его поставки на рынок. Она выполняется в рамках принятия решения, следует ли вообще развивать этот подход или идею.
Скажу несколько слов о том, какие уроки я извлек из этого. Мне не раз приходилось видеть, как команды переходят к этапу поставки, не оценив в должной мере риска реализуемости. Каждый раз, когда вы слышите истории о продуктовых командах, недооценивших объем работ по созданию и поставке чего-либо стоящего, знайте: главная проблема данного просчета кроется именно в этом. Может быть, у разработчиков не было опыта в правильной оценке перспектив, или инженеры и менеджер продукта не в полной мере понимали, что для этого нужно, или последний не дал инженерам-программистам достаточно времени на изучение и анализ ситуации.
Войти с помощью соц. сетей: