Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, watcher, Вы писали:
W>>и на основе моего опыта нужно делать так
M>Опыт-то успешный, или как у остальных?
по всякому
одна поправочка для вашего ответа
все, что вы описали — это для так сказать "типичного стартапа"
и при чем когда все сверху донизу понимают, что они делают "типичный стартап"
на практике это может быть смесью "типичного стартапа" с одним из следующего (причем по разному на разных уровнях и на разных этапах)
— новая версия уже имеющегося и давно продающегося продукта
— заказной проект для конкретного заказчика или набора заказчиков
— развлекалово
у меня был специфический экспириенс по всем этим комбинациям, поэтому и мои мысли правильные и ваши
самый главный вывод на будущее нужно больше думать и больше общаться в самом начале
Re: а какая методология работает в таком вот проекте
Здравствуйте, watcher, Вы писали:
W>а какая методология (или набор методологий) работает в таком вот проекте?
Никакая. Проблема в том, что у вас нет "источника правды". То есть и так степень неопределённости высока, а из-за ЧСВ неопределенность будет нарастать еще больше.
Начать нужно с того, чтобы в команде появился менеджер продукта, который знает рынок. Далее он уже составляет беклог.
А по беклогу можно сначала просто по kanban работать, а при масштабировании перейти на скрам.
Re[2]: а какая методология работает в таком вот проекте
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, watcher, Вы писали:
W>>а какая методология (или набор методологий) работает в таком вот проекте?
G>Никакая. Проблема в том, что у вас нет "источника правды". То есть и так степень неопределённости высока, а из-за ЧСВ неопределенность будет нарастать еще больше. G>Начать нужно с того, чтобы в команде появился менеджер продукта, который знает рынок. Далее он уже составляет беклог. G>А по беклогу можно сначала просто по kanban работать, а при масштабировании перейти на скрам.
как термин "источник правды" звучит на английском?
где написано, что любая методология должна базироваться на источнике правды?
Re[3]: а какая методология работает в таком вот проекте
Здравствуйте, watcher, Вы писали:
W>как термин "источник правды" звучит на английском?
По разному в зависимости от методологии.
W>где написано, что любая методология должна базироваться на источнике правды?
В agile все опирается на беклог, который ведется одним овнером. В тяжелых методологиях есть srs, то есть спецификация требований, и отдельные роли, которые отвечают за srs. А у нас это обычно называется ТЗ/ЧТЗ.
В любой методологии такой «источник правды» присутствует.
Re[2]: а какая методология работает в таком вот проекте
W>на первом этапе W>на втором этапе W>на третьем этапе
А когда же начинать продавать? Тут не хватает самого главного этапа — продаж. Или продажи не предполагаются? Просто пилим бюджет инвестора и сваливаем?
Счастье — это Glück!
Re: а какая методология работает в таком вот проекте
W>д) четких требований в принципе нет, а есть "гениальная или псведогениальная" идея от инвестора, куча готовых аналогов в сети, которые частично тупо клонируются
Если у инвестора нет клиентской базы, кому он будет продавать реалтизацию своей гениальной идеи или нет понимания как ее монетизировать, то никакая методология вообще не нужна.
Счастье — это Glück!
Re: а какая методология работает в таком вот проекте
W>так вот, под какие методологии подпадает W>- начальная части проекта, пока ничего еще не ясно
Если нет заказчика готового сидеть рядом и есть умный чел который знает как надо, то в идеале — ватерфолл. Остальное имеет шанс остановиться не приходя к результату. Результат- сделать прототип. Это такая дема инвестору, на которую он смотрит 5 минут... )))
Надо чтобы стало ясно. Либо экспертно, либо тестированием "на кошках". Денег мало так что надейтесь на эксперта, который должен сказать фиче-лист MVP.
Убейтесь если он будет рисовать правильную архитектуру — все равно ее только на слайды вешать. В общем за 20-40 тыс $ есть надежда наваять прототип версии 2.0...
Задача "главного и умного" сделать архитектуру так чтобы не продолбать сроки и выдать хотя бы 95% функционала. При этом понятно что прототип потом можно будет выкинуть при получении инвестиций.
W>- начальная часть второй фазы разработки, пока ничего тоже в принципее не ясно, но есть куча разнонаправленных интересов уже внутри компании
Ни в коем случае не идти на поводу у желающих улучшить код, покрыть тестами, переделать архитектуру... Пилите MVP дальше и начинайте фиксить баги с помощью костылей.
W>- ну, и третья часть не описанная выше, когда все уже устаканилось и нужно просто тупо идти к цели
Ура есть деньги!!!
А теперь все выкидываем (рефакторим) и начинаем нормальный процесс.
Re: а какая методология работает в таком вот проекте
Здравствуйте, watcher, Вы писали:
W>б) есть опытный разработчик-проектировщик, который знает как все нужно делать и на что можно напоороться, но сам он уже код писать не будет — только менеджмент и написание бумажек
На данном проекте, опытный проектировщик — слабое звено. Либо поручите ему писать код (пригодится, как хороший кодер), либо поручите ему работу по другому проекту. Либо увольте, если он не хочет писать код, и для него нет подходящий работы. В нормальной компании всё должно быть подчинено интересам бизнеса. И если в этих интересах нужно писать код (а не разрабатывать громоздкую архитектуру), то квалифицированный разработчик должен это делать без капризов.
W>в) на разработку начальной версии продукта нанимается 1-3 девелопера на несколько месяцев
Неразумное решение. А о людях Вы подумали? Через 3 месяца собираетесь их уволить? Ещё один весомый аргумент, почему проектировщик должен писать код.
W>д) четких требований в принципе нет, а есть "гениальная или псведогениальная" идея от инвестора, куча готовых аналогов в сети, которые частично тупо клонируются
Необходим бизнес-аналитик или продюсер проекта, которые нечёткие требования заказчика может преобразовать в перечень фич и юз-кейсов. Разумеется, этот перечень должен быть согласован с заказчиком и утвержден. Бизнес-аналитик (или продюсер + бизнес-аналитик) — наиболее важное лицо на данном проекте. Это, кстати, ещё одна возможная ниша для проектировщика, если, конечно, у него есть опыт и понимание, как формулировать фичи и писать юз-кейсы.
W>е) а еще есть общий план заключающийся в том, что после того, как начальный бюджет будет использован может быть неожиданный перерыв с финансированием и все девелоперы свалят, но потом можно будет найти много новых денег с помощью разработанного прототипа
Причина, по которой не следует нанимать сотрудников ради этого проекта (во всяком случае, на постоянную работу).
