Павел Афанасенко Templar Павел Афанасенко
ОК. Еще несколько вопросов на сегодня:
1. Какова средняя трудоемкость реализации одного требования (в идеальных днях, например).
2. Непонятно, какие затраты на кастомизацию. Дайте плз ожидаемую трудоемкость кастомизации (в идеальных днях).
3. Сколько человек в команде? Или команды нет?
Будем считать, что команды пока нет. Есть бюджет, менеджер продукта и вы.
Трудоемкость по требованиям пока неясна, но есть ограничения бюджета.
Доработки: не более 1-2 выделенных людей на 2-4 месяца проекта.
Ситуация в целом понятна. Сегодня в течение дня отпишу, как бы стал действовать я в такой ситуации.

Ну так вот. Я бы сначала связался с двумя-тремя крупными клиентами и вовлек их в процесс разработки софта в качестве потенциальных заказчиков - так и продукт станет ближе к нишевым клиентам, и его продажа этим заказчикам начнется одновременно с их участием в разработке.

Затем я бы организвал следующую команду: PM, 3-5 разработчиков (чем меньше, тем лучше), 1-3 представителя от клиентов, менеджер продукта. На менеджера продукта я бы навесил роль Product Ownera и тестера разрабатываемого продукта. Далее, я бы определил список работ (backlog) с помощью заказчиков, отсортировал бы работы по убыванию важности функционала, и стал бы реализовывать эти черты. В работе использовал бы скорее всего 2-х недельные итерации (или однонедельные - в зависимости от трудоемкости реализации черт). В конце каждой итерации собирал бы заказчиков, выслушивал их обратную связь о создаваемом продукте. Если заказчики довольны/готовы покупать и бюджет позволяет, то в процессе работы нанял бы еще людей - количество зависит от того, насколько быстро удается справляться с разработкой существующей командой и какие конкретные задачи/сроки стоят.

Так как бюджет ограничен, сроки скорее всего тоже ограничены, качество мы выдерживаем высоким, то естественным представляется ограничение продукта по функционалу. Поэтому делаем самые важные вещи вперед и стремимся быть готовыми к тому, что деньги могут в любой момент закончиться - это значит, продукт в любой момент времени должен быть максимально готов к выпуску - приемочное и модульное тестирование must have! Если менеджер продукта не справляется с тестированием, найду профессионального тестера, пусть даже в ущерб скорости разработки - качество важнее, чем еще одна (и даже десять) фич.

Что касается кастомизации, то я бы имел ее в виду, но не заострял бы на ней внимание. Продукт должен сначала пройти испытание рынком, чтобы мы могли понимать, что рынок для продукта есть и имеет смысл продукт кастомизировать.

Ну как-то так :)

nibbles Павел АфанасенкоГотов быть неправым в вопросах теологии :) Давайте заменим слово "вера" на какое-нибудь другое, например на "уверенность в успехе".
Согласны ли Вы с такой фразой: "Уверенность в успехе должна быть чем-то подкреплена(опытом, знаниями, etc). Тем она и отличается от надежды на успех"?
Безусловно.
Вопросы:
1. Чем подкреплена "уверенность в успехе" членов "дрим-тим"?
2. Чем "уверенность в успехе" членов "дрим-тим" отличается от "уверенности в своих силах" профессионалов из "обычных команд"?
3. Является ли декларируемая "уверенность в успехе" единственным отличием "дрим-команды" от "обычной команды"?

можно в любом порядке
Отвечаю:
1. "Уверенность в успехе" членов "дрим-тим" подкреплена предыдущими достижениями.
2. "Уверенность в успехе" членов "дрим-тим" ничем не отличается от "уверенности в своих силах" профессионалов из "обычных команд" за исключением того, что "дрим-тим" добилась сверхрезультатов по сравнению с обычной командой. Соответственно, "дрим-тим" может большего, чем обычная команда, и уверена в том, что она это сделает.
3. "уверенность в успехе" является скорее не отличием "дрим-команды", а отличительным признаком. В том смысле, что первичным конечно же являются достижения команды "дрим-тим" - отсюда и растет уверенность, дух победителя

Сергей Васкецов iscrafmПрямая аналогия в армии: командир и замполит.
Мне ближе позиция Павла Афанасенко к "корабельный священник". Та же неумеренная вера в свои возможности, ну просто один в один.
Ищете в своем опыте нечто, с чем уже сталкивались, о чем читали? Чтобы классифицировать меня? Понимаю :)
Предлагаю посмотреть на еще одну http://www.youtube.com/watch?v=BAI5x4BBD6o

С.Архипенков
...решил вставить свое ИМХО в поддержку Павла, хотя, уверен, лично он в этом не нуждается...
Сергей, спасибо за поддержку! И Вы правы, я прекрасно справляюсь и без нее :)

Давайте я поясню свою стратегию по разработке нишевого продукта.

Ну во-первых, то, что обнаружена новая ниша - это замечательно! Только новая ниша не гарантирует продажу продуктов для нее автоматически. Для продаж нужно сформировать рынок, у клиентов нужно сформировать потребности. До этого, ниша существует только в головах у того, кто это выявил.

Я про то, что существование ниши нужно доказать. Доказать продажами. А лучшие клиенты в любой индустрии - это лидеры рынка:
Они большие, поэтому им можно продать много

Они лидеры, больше всего знают о том рынке, на котором работают, и поэтому с них можно снять большее и точнее информации о том, в чем нуждаются потребители данного продукта вообще.

Продав продукт лидерам, мы сразу получим нехилый пиар, шансы на то, что остальной рынок выстроится за лидерами в очередь за продуктом потому, что его купили лидеры, очень велики.

Дополнение ко второму пункту: первичное знание о том, что нужно клиенту, находится все-таки у клиента, а не у вендора. У нас в компании часто бывает, что приходит к тебе какая-нибудь Нокия со своей проблемой, и ты ее решаешь. А потом выясняется, что такая же потребность есть и у остальных компаний, просто они ее не осознают пока. И ты берешь солюшн, который сделал для Нокии, превращаешь его в продукт и продаешь всем остальным. Такая стратегия работает - неоднократно убеждался на практике.

Конечно, делая решение для 2-3 компаний, пусть даже и лидеров, ты рискуешь превратиться в поставщика только для этих компаний. Ну так это в любом случае венчур, и зная этот риск, его можно избежать или минимизировать. И риски сделать решение для 2-3 компаний, которые его купят, все равно не так болезненны, как риски сделать кастомизированный продукт для 10-100 компаний, который никто не купит.

Вовлекая 2-3 лидеров в процесс создания продукта, я решаю две задачи:

Вытаскиваю потребности клиента, делаю продукт точнее к решению проблем клиентов

Осуществляю неявную продажу продукта еще до того, как он разработан, и в процессе его разработки

Если клиент отказывается участвовать в работе над продуктом, это сигнал мне о том, что может быть потребность не очень существует и продукт может быть не востребован рынком. В таком случае я откладываю запуск работ до тех пор, пока не удостоверюсь в нужности продукта.

В разработке нового продукта я исхожу из стратегии его скорейшего вывода на рынок. Пока продажи не начались, рынок продукта существует только в головах. Для того, чтобы рынок из виртуального стал реальным, продукт нужно продавать. Делая продукт, мы тратим деньги и не продаем. Но начать продажи, не имея ничего, можно только в ограниченном объеме (тем 2-3 клиентам). Поэтому, нужно сделать нечто, что имеет существенную ценность для клиентов, и начать продавать как можно быстрее. Таким образом, мы сокращаем период неопределенности, снижаем риски провала по cash flow, получаем обратную связь от рынка, что позволит нам скорректировать курс, если это необходимо. Если все пойдет хорошо, функционал всегда можно нарастить, пусть даже путем написания второй версии продукта с нуля. Это гораздо лучше, чем потратить кучу времени и денег, выпустить развесистый продукт, который не будет востребован рынком.

Про аналитика. Его можно ввести, например, в SCRUM такая роль в команде существует. Я не стал этого делать потому, что изначально принял решение делать продукт, основываясь на потребностях 2-3 клиентов - помощников в создании продукта. А там я большой аналитики не вижу (по крайней мере, в таком ментальном упражнении :)).

И последнее - про качество. Мое видение здесь такое: качество - это твоя репутация. Которая, как известно, зарабатывается долго. А сделав что-то плохо один раз, ты теряешь репутацию сразу и надолго, если не навсегда. Поэтому в дилемме функционал-качество мой выбор всегда на стороне качества.

Много букфф написал :) И, как ни странно, почти все они не про Agile

Коллеги!

Своим постом я закрываю свое участие в этой дискуссии.
Живое двухнедельное обсуждение показало, что тема управления проектами и роли руководителя проекта очень важна с современной разработке софта. И единства во взглядах здесь нет и быть не может.

Все это время я стремился максимально подробно описать свое видение и отношение к тому, каким должен быть руководитель проекта и какую команду он может построить. Лично для меня это обсуждение принесло огромную пользу! Надеюсь, что и вам тоже. Огромное вам спасибо!

Удачи всем нам!

Mainframe_старыйПавел, , я тут только хотела Вам задать конкретный вопрос, связанный с человеческим фактором в управлении проектом. Задам, а вы уже ответите, если захотите. Ситуация - есть проект - внедрение своих разработок в другой организации. внедрение осуществляют две основные группы , одна из которых наняла другую для выполнения большей части работ, так как у самой нет ни таких разработок, ни опыта такого внедрения, но она находится территориально рядом с заказчиком. В процессе работы нанятая группа, будучи заинтересованна во внедрении своих разработок, делает все, чтобы внедрение прошло в нужные сроки, в том числе и постоянно запрашивает первую фирму (которая на территории закзачика базируется) о различных текущих вопросах ( без которых дальнейшие работы стопорятся). руководитель проекта от первой фирмы очнеь болезненно воспринимает ситуацию, т.е. он воспринимает вопросы как понукание, как желание контролировать их действия. Вопрос, что делать нанятой фирме с точки зрения - люди главное, каким образом продвигать проект, несмотря на то, что руководитель от первой конторы не понимает ни в предметной области, ни в руководстве проектами и не пытается вникнуть, но зато очнеь обижается ?

Ситуация ясна. Свое представление того, что бы я сделал в такой ситуации, я готов описать, но не в рамках этого топика. Давайте перенесем обсуждение в отдельный топик. Или через электропочту. Моя: Pavel [точка] Afanasenko [гав] gmail [точка] com