Войти в систему
Войти с помощью соц. сетей:
Для того чтобы подтвердить наличие технических возможностей идеи, инженеры-программисты стараются ответить на ряд вопросов по существу дела:
Я не намерен вас пугать. В большинстве случаев ваши разработчики, оценивая идеи новых продуктов на этапе исследования, быстро рассмотрят все эти пункты и ответят, что проблем нет. По большому счету задачи не такие уж и новые, и разработчики уже много раза делали что-то подобное.
Тем не менее к некоторым идеям это не относится, и тогда ответить на эти или даже на многие из перечисленных вопросов бывает очень трудно.
Приведу весьма распространенный пример: сегодня многие команды оценивают технологию машинного обучения, обдумывают решения типа «создавать или покупать» и прикидывают, подходит ли она для выполняемой ими задачи — и, если говорить шире, пытаются оценить ее потенциал.
С удовольствием дам вам несколько важных практических советов на этот счет. Проведение еженедельных планерок, на которых менеджер продукта, предлагая инженерам-программистам готовый список идей, требует дать их оценку с точки зрения затрат времени, насчитать баллы за пользовательскую историю или оценить в других единицах усилий, которые понадобятся для ее реализации, — это верный рецепт краха. Если вы припрете разработчика к стене, не дав ему времени расследовать и обдумать идею, то, скорее всего, получите от него консервативный ответ, нацеленный отчасти на то, чтобы его оставили в покое. Если же ваши инженеры-программисты вместе с другими членами команды тестировали идеи на потребителях (с применением прототипов) и своими глазами видели их проблемы и то, как они отнеслись к этим идеям, значит, у них, по всей вероятности, уже было некоторое время на их обдумывание. Короче говоря, если вы считаете идею стоящей, дайте специалистам возможность изучить и проанализировать ее.
Не следует ставить вопрос так: «Ну что, сможете это сделать?» Попросите инженеров-программистов ознакомиться с идеей и ответить на вопрос: «Как, по-вашему, это лучше сделать, и сколько времени это займет?».
Иногда чуть позже они возвращаются к менеджеру со словами, что для того, чтобы ответить на один или несколько из перечисленных вопросов, им нужно создать прототип для проверки реализуемости замысла. В таком случае сначала обдумайте, заслуживает ли потенциал идеи столь существенных трат времени на этапе исследования. И если да, давайте добро на дальнейшую работу.
И последнее важное замечание об оценке осуществимости новых идей: я не раз встречал и до сих пор встречаю менеджеров продукта, которым ненавистна любая идея, если на ее обдумывание инженеры-программисты просят дать им время. Этим менеджерам такой ответ говорит о том, что идея рискованная и на ее реализацию уйдет слишком много времени (в лучшем случае). Обычно я им говорю, что мне такая ситуация, напротив, очень нравится по нескольким причинам. Во-первых, многие удачные идеи относительно продуктов основываются на таких подходах к решению, которые стало возможным применять только сейчас, что означает появление новой технологии, на изучение которой людям нужно время. Во-вторых, по моему опыту, если технарям дают хотя бы два дня на изучение и обдумывание идеи, они часто возвращаются не только с хорошими ответами на вопросы о возможностях ее реализации, но и с более перспективными способами решения проблемы. В-третьих, такой подход обычно очень мотивирует команду, поскольку обеспечивает людей возможностью учиться и проявлять свои таланты и способности.
Этап исследования для аппаратных продуктов
Как известно, сегодня очень многие высокотехнологичные продукты включают в себя аппаратный элемент. Телефоны и часы, робототехника и автомобили, медицинская аппаратура и термостаты — смарт-устройства повсюду. Каким образом включение в уравнение аппаратных средств влияет на все, что мы с вами к этому моменту обсудили?
Некоторые различия в подходах очевидны, например, необходимы другие инженерно-технические навыки, потребность в промышленном дизайне. И конечно, на производство «железа» по-прежнему уходит значительно больше времени, чем на написание софта, хотя, нужно признать, тут ситуация постоянно улучшается.
По большей части все, что мы с вами обсудили, применимо и к аппаратным продуктам, хоть есть и дополнительные вызовы. Скажу больше: когда в уравнение включается аппаратное обеспечение, методики исследования продукта, о которых мы говорили в предыдущих главах, приобретают большое значение, и в первую очередь это касается прототипирования. При разработке «железа» ошибки обходятся гораздо дороже и в сроках, и в деньгах. При работе над софтом исправление ситуации стоит относительно недорого, а с аппаратными продуктами все не так просто. В частности, создание «железа» сопряжено со значительно большими рисками технической осуществимости; возникают дополнительные риски и в связи с бизнес-жизнеспособностью решения. Например, для аппаратного обеспечения требуется более сложный анализ компонентов и производственных затрат и такое же прогнозирование. Хотя, нужно признать, в последние годы процедура прототипирования аппаратных средств усовершенствовалась и упростилась благодаря появлению технологии 3D-печати.
И главное, аппаратные продукты требуют от разработчиков агрессивного подхода к работе с рисками ценности, юзабилити, реализуемости и бизнес-жизнеспособности, а еще приходится намного выше поднимать планку веры в успех продукта, прежде чем браться за его изготовление.
Войти с помощью соц. сетей: