Здравствуйте, watcher, Вы писали:

W>и на основе моего опыта нужно делать так

Опыт-то успешный, или как у остальных?

W>на первом этапе

На первом этапе никому ничего не ясно. Не ясно взлетит или не взлетит. Не ясно что именно взлетит. Не ясно как это произойдет. До тех пор пока стартап превратится в бизнес ему предстоит пройти несколько pivot point в которых он будет меняться до неузнаваемости. Поэтому на первом этапе у разработки две цели: делать все максимально быстро и делать все максимально дешево. Все остальное должно приносится в жертву этим целям, без исключений.

W>1. изначально нужно писать много много много функциональных/технических спецификаций и рисовать много много много мокапов

При таком бюджете вообще не нужно тратить деньги на спецификации и мокапы. Нужны универсальные люди, которые и UX, и дизайн, и верстка, и бэкенд, и все остальное. Эти люди должны максимально быстро клепать максимально дешевые прототипы. Прототипы должны использоваться на реальных пользователях и мгновенно дорабатываться или выкидываться на помойку. Вот когда бизнес-концепция устаканится и контуры продукта будут четко видны можно потихоньку начинать писать спецификации для версии 2.0, но не раньше. Единственная документация которая имеет смысл на этом этапе, это рабочий дневник проекта. Если кто не видел, это такой документ в который каждый день записывается что произошло, какие проблемы были обнаружены и какие решения и почему были приняты.

W>2. спланировать максимальное использование левых готовых компонентов и фреймворков

При этом нужно учитывать риск проблем с чужими решениями который может свести на нет всю выгоду. Самая оптимальная стратегия выглядит так:

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

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

W>3. четко договорить с инвестором какие 1-3 фичи проекта являются ключевыми на данном этапе

Бесполезно. Инвестор сам не понимает какие фичи ключевые, а какие нет. Помогут только ранние прототипы и раннее тестирование на реальном рынке. Если инвестор склонен сперва сделать проект на 100% готовым и только потом выходить на рынок, проект провалится с вероятностью 100%.

W>4. затем нужно нанять дешевых удаленщиков из бедных стран за 15-20 usd в час (при условии, что пункт 1 сделан грамотно, то не слишком высокая квалификация девелоперов — это не проблема) — нужно учитывать, что практически все будут работать парт тайм, а если кто-то будет говорить о фулл тайме, то это будет очень плохой фулл тайм или липовые часы

Ни в коем разе. Удаленщики работают медленно. Их можно нанимать когда сроки вообще не важны. В стартап нужно нанимать людей-орекстров, закрывающих как можно больше компетенций разом. Коммуникации между людьми занимают время, поэтому людей должно быть как можно меньше. Лучше нанять одного дорогого, чем трех дешевых. Вся команда обязательно должна находится в одном месте, и в этом же месте должен находится лицо принимающее решения по проекту. Если это инвестор, он должен сидеть в той же комнате, или хотя бы появляться раз в пару дней на несколько часов.

W>5. в процессе разработки мгновенно писать документацию по всему что делается

Ни в коем случае. Документацию писать очень дорого, особенно если это делают сами программисты. Команда должна четко понимать что она делает прототип для тестирования бизнес-идеи. Все побочные активности должны идти вторым приоритетом.

W>6. 1 ключевую фичу наверное можно даже покрыть тестами

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

7. Проект должен биться на слабо связанные части между которыми должны быть понятные интерфейсы. Не программные интерфейсы, а HTTP, REST, *MQ, обмен через файлы и т.п. Разные части лучше писать на разных языках, никакую общую кодовую базу не вводить. Да, получится зоопарк, но это убережет от ситуации когда весь продукт превратился в сапгетти монстра в котором никто до конца не разбирается.

W>на втором этапе

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

W>1. договориться о том какие 1-3 части проекта являются ключевыми и вести для них разработку по принципам указанным выше

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

W>2. при этом поскольку бюджет побольше уровент нанимаемых людей можно поднять, а основной задачей здесь будет натренировать команду на готовом коде, пока менеджеры/инвесторы разуливают всякие междусобойчики

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

W>3. разруливание междусобойчиков будет продолжаться либо пока они не разрулятся сами собою, либо пока проект не сдохнет/зайдет в тупик из-за ошибок сделанных в первой фазе, либо пока новая команда не "съест" 100-200К$ — после этого у главного инвестора начнется отрезвление и все устаканиться

W>на третьем этапе

На третьем этапе проект вышел на самоокупаемость и над ним уже не стоит перспектива закрытия по исчерпанию бюджета. Тут можно увеличить бюджет разработки, тем более что к этому моменту фичалист вырос до 300 листов. В этот момент нужно убедиться что в проекте есть роль product manager и такой человек один и только один. Этот product manager садится и приоритезирует список фич составляя планы развития продукта на 1 месяц, 3 месяца, 6 месяцев, 1 год, 3 года и 10 лет. С точки зрения разработки основная задача обеспечить равномерную скорость внесения фич. Для этого нужно грамотно разделить время между добавлением новых фич и рефакторингом старого кода. Вторая задача — обеспечить распространение знаний из голов разработчиков прототипа в головы вновь нанятых сотрудников. Самый естественный способ достичь этого — передать новых разработчиков под командование старожилов. При этом нужно последовательно вбивать в голову всем присутствующим следующую мысль: "При разработке прототипа все было принесено в жертву двум вещам, скорости разработки и дешевизне результата. Это позволило компании выйти на рынок, но теперь пришло время других приоритетов стабильной скорости разработки и стабильному качеству. А это, в свою очередь, требует снижения темпа добавления новых фич" В корпоративную культуру должен быть внесен мем: "Вот это Паша. В 2015 он в одно лицо сделал первую версию продукта за три месяца. Да, продукт был так себе, кое-какое наследие мучает нас до сих пор, но именно Паша помог компании стать тем, что она есть" Одновременно с этим должна повышаться управляемость разработки. Если на первом этапе разработчик мог сам решить, сам сделать, сам выкатить пользователям и показать инвестору готовы результат, то теперь такое должно стать невозможным. У каждого сотрудника должна появиться четкая зона ответственности, а отношения между сотрудниками должны быть четко регламентированы. Короче, нормальный корпоративный порядок.

W>1. здесь можно начинать использовать agile, scrum и пр. и все делать как написано в книжках

Методологии в данном случае это вообще вторично. На первом этапе проект больше напоминает "хакотон в пижамах" чем привычную разработку. На втором — попытку идти по морю в дырявой лодке. И только на третьем этапе уже можно играть в методологии, но к тому моменту это уже не интересно.

Здравствуйте, Baudolino, Вы писали:

B>BDD+SCRUM

или сокращённо BD/SM

сейчас я напишу свое мнение, как нужно делать, а вы прокомментируйте

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

и на основе моего опыта нужно делать так

на первом этапе
1. изначально нужно писать много много много функциональных/технических спецификаций и рисовать много много много мокапов
2. спланировать максимальное использование левых готовых компонентов и фреймворков
3. четко договорить с инвестором какие 1-3 фичи проекта являются ключевыми на данном этапе
4. затем нужно нанять дешевых удаленщиков из бедных стран за 15-20 usd в час (при условии, что пункт 1 сделан грамотно, то не слишком высокая квалификация девелоперов — это не проблема) — нужно учитывать, что практически все будут работать парт тайм, а если кто-то будет говорить о фулл тайме, то это будет очень плохой фулл тайм или липовые часы
5. в процессе разработки мгновенно писать документацию по всему что делается
6. 1 ключевую фичу наверное можно даже покрыть тестами

на втором этапе
1. договориться о том какие 1-3 части проекта являются ключевыми и вести для них разработку по принципам указанным выше
2. при этом поскольку бюджет побольше уровент нанимаемых людей можно поднять, а основной задачей здесь будет натренировать команду на готовом коде, пока менеджеры/инвесторы разуливают всякие междусобойчики
3. разруливание междусобойчиков будет продолжаться либо пока они не разрулятся сами собою, либо пока проект не сдохнет/зайдет в тупик из-за ошибок сделанных в первой фазе, либо пока новая команда не "съест" 100-200К$ — после этого у главного инвестора начнется отрезвление и все устаканиться

на третьем этапе
1. здесь можно начинать использовать agile, scrum и пр. и все делать как написано в книжках

Здравствуйте, watcher, Вы писали:

W>на самом деле я уже работал в нескольких аналогичных проектах и в качестве разработчика, и в качестве разработчика-проектировщика, и в качествке менеджера-проектировщика
W>так что для меня это уже проверенный сценарий

Раз проверенный сценарий, делитесь, как вы с разрывом в n месяцев передаёте опыт и добиваетесь, чтобы наработки от почасовиков хоть как-то годились бы для команды второго набора

Это кун-фу пожалуй покруче исходной задачи будет.

а какая методология (или набор методологий) работает в таком вот проекте?

а) есть инвестор с минимумом денег, скажем 20-40К$
б) есть опытный разработчик-проектировщик, который знает как все нужно делать и на что можно напоороться, но сам он уже код писать не будет — только менеджмент и написание бумажек
в) на разработку начальной версии продукта нанимается 1-3 девелопера на несколько месяцев
г) human factor у всех игроков в проекте (инвестор, проектировщик, девелоперы) ну просто зашкаливает
д) четких требований в принципе нет, а есть "гениальная или псведогениальная" идея от инвестора, куча готовых аналогов в сети, которые частично тупо клонируются
е) а еще есть общий план заключающийся в том, что после того, как начальный бюджет будет использован может быть неожиданный перерыв с финансированием и все девелоперы свалят, но потом можно будет найти много новых денег с помощью разработанного прототипа
ж) как только пойдет много денег придут новые инвесторы и менеджеры с кучей своих закидонов и идей, а команду всю или почти всю придется нанимать заново
з) в этот момент начнутся попытки внедрения всяких методологий

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

Здравствуйте, watcher, Вы писали:

W>а какая методология (или набор методологий) работает в таком вот проекте?

W>в) на разработку начальной версии продукта нанимается 1-3 девелопера на несколько месяцев
W>г) human factor у всех игроков в проекте (инвестор, проектировщик, девелоперы) ну просто зашкаливает
W>д) четких требований в принципе нет, а есть "гениальная или псведогениальная" идея от инвестора, куча готовых аналогов в сети, которые частично тупо клонируются
W>е) а еще есть общий план заключающийся в том, что после того, как начальный бюджет будет использован может быть неожиданный перерыв с финансированием и все девелоперы свалят, но потом можно будет найти много новых денег с помощью разработанного прототипа
W>ж) как только пойдет много денег придут новые инвесторы и менеджеры с кучей своих закидонов и идей, а команду всю или почти всю придется нанимать заново
W>з) в этот момент начнутся попытки внедрения всяких методологий

Немножечко диктатуры, и живительных расстрелов.

По всем процитированным пунктам.

Здравствуйте, Baudolino, Вы писали:

B>BDD+SCRUM

1. ЧСВ в команде
2. Команда знает, что через примерно три месяца "всем спасибо, до свидания"
3. Бизнес-плана нет, заказчика по факту нет.
4. Тимлид ожидает, что методологии будут перевнедрять после повторного запуска продукта.

Road to fail, тут хоть ночные хакфесты в пижамах проводи — не поможет.

1-3 дешёвых девелопера и проектировщик при таком бюджете и тех сроках которые позволяет такой бюджет — разброд, шатание и пустая трата времени и денег на коммуникацию.

План видится примерно такой:
Опытный разработчик-проектировщик описывает грабли касающиеся предметной области в текстовике, подписывается отвечать на вопросы в скайпе и проверять коммиты под обещание денег с фазы 2. Исполнителем берётся суровый опытный контрактор, который, сжирая бюджет за троих, в режиме еждедневных диалогов с инвестором реализует фазу 1. Фаза 2 делается с нуля, лучше если тим-лидом у них будет тот самый контрактор, с теми людьми которые его устроят и с тем процессом который он наладит.

Это если хочется дойти до фазы 2. А если тупо бюджет освоить, то ещё минимум писатель скриптов автоматизированного тестирования нужен.

Здравствуйте, Baudolino, Вы писали:

B>Все упирается в личность руководителя. Людьми с ЧСВ тоже можно эффективно управлять, знаю по своему опыту.

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

B>Результатом не является бинарное состояние "сделали/не сделали идеальный проект". За $20-40К вполне можно в некоторых доменах получить работающий прототип, пусть и с кучей багов/кривой архитектурой.

Результатом будет являться "прожрали все деньги, что-то делали, но продукта, который способен хотя бы потенциально принести деньги, не получилось"

Здравствуйте, watcher, Вы писали:


W>так вот, под какие методологии подпадает
W>- начальная части проекта, пока ничего еще не ясно
Если нет заказчика готового сидеть рядом и есть умный чел который знает как надо, то в идеале — ватерфолл. Остальное имеет шанс остановиться не приходя к результату. Результат- сделать прототип. Это такая дема инвестору, на которую он смотрит 5 минут... )))

Надо чтобы стало ясно. Либо экспертно, либо тестированием "на кошках". Денег мало так что надейтесь на эксперта, который должен сказать фиче-лист MVP.
Убейтесь если он будет рисовать правильную архитектуру — все равно ее только на слайды вешать. В общем за 20-40 тыс $ есть надежда наваять прототип версии 2.0...

Задача "главного и умного" сделать архитектуру так чтобы не продолбать сроки и выдать хотя бы 95% функционала. При этом понятно что прототип потом можно будет выкинуть при получении инвестиций.


W>- начальная часть второй фазы разработки, пока ничего тоже в принципее не ясно, но есть куча разнонаправленных интересов уже внутри компании

Ни в коем случае не идти на поводу у желающих улучшить код, покрыть тестами, переделать архитектуру... Пилите MVP дальше и начинайте фиксить баги с помощью костылей.


W>- ну, и третья часть не описанная выше, когда все уже устаканилось и нужно просто тупо идти к цели
Ура есть деньги!!!
А теперь все выкидываем (рефакторим) и начинаем нормальный процесс.

BDD+SCRUM

BDD — описание сценариев взаимодействия, много прототипирования в тулах типа Axure, тестирование на пользователях (инвесторе,его жене и паре нормальных), задачи на разработку от протестированных сценвариев и прототипов.
SCRUM — регулярное планирование спринтов удержит фокус проекта на самом важном и позволит адаптироваться к меняющимся требованиям.
Можно сделать спринты по схеме 1+2: неделя прототипирования и пользовательского тестирования + 2 недели разработки на основе прототипа. В первую неделю, пока идет прототипирование, разработчики могут решать технические задачи — автоматизация, рефакторинги, библиотечки и фреймворки, изучение технологий и пр.

Здравствуйте, Sinix, Вы писали:

S>1. ЧСВ в команде
Все упирается в личность руководителя. Людьми с ЧСВ тоже можно эффективно управлять, знаю по своему опыту.

S>2. Команда знает, что через примерно три месяца "всем спасибо, до свидания"
Контракторов тоже можно нормально замотивировать. Например, деньгами в размере 20-50% месячной зп в виде бонуса.

S>3. Бизнес-плана нет, заказчика по факту нет.
Бизнес-план хреновый (слепить прототип и топать на рынок), но он все-таки есть. Заказчик, очевидно, тоже есть — это инвестор проекта, вкладывающий деньги в конкретную идею.
Для гаражного стартапа с минимальной суммой инвестиций ($40К это смешные деньги) важнее нащупать идею, чем иметь детальный бизнес-план.

S>4. Тимлид ожидает, что методологии будут перевнедрять после повторного запуска продукта.
Изменение методологии — это нормальное явление в любой команде разрабатывающей продукт больше чем один месяц. Условия меняются, нужно адаптировать к ним процесс. Команда выросла — нужно адаптировать процесс.
Поэтому я бы не назвал это проблемой для адекватного тимлида. Нужно уметь работать в любом процессе, и уметь его менять, как снизу, так и сверху.

S>Road to fail, тут хоть ночные хакфесты в пижамах проводи — не поможет.
Результатом не является бинарное состояние "сделали/не сделали идеальный проект". За $20-40К вполне можно в некоторых доменах получить работающий прототип, пусть и с кучей багов/кривой архитектурой.
Если не взлетит из-за плохой организации, инвестор получит за эти деньги очень интересный и полезный опыт. Если не взлетит из-за провала идеи — нормально, нужно думать дальше.
Тут важно понимать, что вероятность неудачи у того, что не попробовал — 100%, а у того, кто попробовал, шансы преуспеть все-таки есть. И хорошо то, что люди все-таки задумались о том, как организоваться, и спросили совета. Совсем не обязательно в славной российской традиции закидывать их говном.

Здравствуйте, Baudolino, Вы писали:

S>>1. ЧСВ в команде
B>Все упирается в личность руководителя. Людьми с ЧСВ тоже можно эффективно управлять, знаю по своему опыту.
Так руководитель тоже... того

human factor у всех игроков в проекте (инвестор, проектировщик, девелоперы) ну просто зашкаливает

Т.е. обратная связь (ключевое в agile и в прочих, завязанных на микроитерации) уже не работает.


S>>2. Команда знает, что через примерно три месяца "всем спасибо, до свидания"
B>Контракторов тоже можно нормально замотивировать. Например, деньгами в размере 20-50% месячной зп в виде бонуса.
Более-менее специалистов — нет. Им нафиг не сдалось вкалывать в авральном режиме n месяцев, и затем, только команда начала срабатываться, искать новую работу.


S>>3. Бизнес-плана нет, заказчика по факту нет.
B>Бизнес-план хреновый (слепить прототип и топать на рынок), но он все-таки есть. Заказчик, очевидно, тоже есть — это инвестор проекта, вкладывающий деньги в конкретную идею.
Нет. Биз план в частности подразумевает, что заказчик имеет чОткие критерии: что он должен получить и как он может проверить, что получил именно то, что хотел.
Иначе это не биз-проект, а благотворительность социальный перформанс.

B>Для гаражного стартапа с минимальной суммой инвестиций ($40К это смешные деньги) важнее нащупать идею, чем иметь детальный бизнес-план.
+1


S>>4. Тимлид ожидает, что методологии будут перевнедрять после повторного запуска продукта.
B>Изменение методологии — это нормальное явление в любой команде разрабатывающей продукт больше чем один месяц. Условия меняются, нужно адаптировать к ним процесс. Команда выросла — нужно адаптировать процесс.
Если я правильно понял топикстартера, то предполагается:
1. потратить n месяцев
2. разогнать команду
3. ещё через n месяцев начать с другой командой, менеджерами и методологией.

Если это не эталонный хитрый план, то что?


B>Поэтому я бы не назвал это проблемой для адекватного тимлида. Нужно уметь работать в любом процессе, и уметь его менять, как снизу, так и сверху.
B>Результатом не является бинарное состояние "сделали/не сделали идеальный проект". За $20-40К вполне можно в некоторых доменах получить работающий прототип, пусть и с кучей багов/кривой архитектурой.
B> И хорошо то, что люди все-таки задумались о том, как организоваться, и спросили совета. Совсем не обязательно в славной российской традиции закидывать их говном.
1. Ну так мы о успехе проекта или о "прокачать скилл тимлида"?
2. Прототип всё-таки подразумевает бизнес план, а не фигак-фигак и смотрим что вышло.
3. Ну а чем тут поможешь, при такой постановке задачи-то? Эт практически как "я прыгнул с 18 этажа, что мне делать?". Шансы научиться летать есть конечно, но я ставлю на гравитацию.

Здравствуйте, watcher, Вы писали:

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

Перерыв в инвестировании — значит идея не взлетела и можно смело разбегаться. Нов целом инвестор нищеброд и за копейки хочет что-то. По идее 20-40k это 2 хороших девелопера на полгода, без всяких менеджментов, бумажек и спецификаций. Что-то может быть, но первичнее продукт с ключевыми фичами. Тесты нафиг не нужны тут.

On 26.03.2015 19:23, watcher wrote:

> на первом этапе
> 1. изначально нужно писать много много много функциональных/технических
> спецификаций
нет

> и рисовать много много много мокапов
да

> 2. спланировать максимальное использование левых готовых компонентов и
> фреймворков
нет

> 3. четко договорить с инвестором какие 1-3 фичи проекта являются
> ключевыми на данном этапе
да

> 4. затем нужно нанять дешевых удаленщиков из бедных стран за 15-20 usd в
> час (при условии, что пункт 1 сделан грамотно, то не слишком высокая
> квалификация девелоперов — это не проблема) — нужно учитывать, что
> практически все будут работать парт тайм, а если кто-то будет говорить о
> фулл тайме, то это будет очень плохой фулл тайм или липовые часы
нет, надо 1-2 нормальных. Которым можно показать мокапы, а они сами
выберут фреймворки, компоненты и т.п. Правда как их найти на такие
условия — хз.

> 5. в процессе разработки мгновенно писать документацию по всему что делается
нет

> 6. 1 ключевую фичу наверное можно даже покрыть тестами
нет

> на втором этапе
об этом я бы не думал от слова вообще, до завершения первого.

--
WBR,
Serge.

Здравствуйте, diez_p, Вы писали:

_>Здравствуйте, watcher, Вы писали:

_>Мне кажется лучше постараться нанять пару неплохих девелоперов, которые с вменяемым качеством напишут прототип. Предполагаю, что дешевые разработчики из бедных стран напишут такой спагетти код, который убьет проект и если идея окажется успешной, придется все переписывать.
_>Это избавит вас от тонны спецификаций, девелоперы сами знают компоненты и фреймворки. Кому нужна документация я тож не знаю, обычно ее пишут уже на продукт, пишет девочка за копейки, но ее все равно никто не читает и звонят в саппорт.

это слишком дорогое и рискованное решение в условиях ограниченного бюджета и ограниченного набора известных требований

но это хороший вариант, если для начала есть 100К$, а не 30K$

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, watcher, Вы писали:

W>>на самом деле я уже работал в нескольких аналогичных проектах и в качестве разработчика, и в качестве разработчика-проектировщика, и в качествке менеджера-проектировщика
W>>так что для меня это уже проверенный сценарий

S>Раз проверенный сценарий, делитесь, как вы с разрывом в n месяцев передаёте опыт и добиваетесь, чтобы наработки от почасовиков хоть как-то годились бы для команды второго набора

S>Это кун-фу пожалуй покруче исходной задачи будет.


долговременные доаеренные личные отношения между инвесторами и тем человеком, который все начал, выражающиеся в гибкой жирной оплате труда и ненапряжном графике, при котором искать др работу не имеет смысла

в идеале должен присутствовать "призрак кнута" и человек, который все начал должен понимать, что если что не так, то его (возможно) подвесят за гениталии
как минимум финансово

Здравствуйте, hrensgory, Вы писали:


>> 4. затем нужно нанять дешевых удаленщиков из бедных стран за 15-20 usd в
>> час (при условии, что пункт 1 сделан грамотно, то не слишком высокая
>> квалификация девелоперов — это не проблема) — нужно учитывать, что
>> практически все будут работать парт тайм, а если кто-то будет говорить о
>> фулл тайме, то это будет очень плохой фулл тайм или липовые часы
H>нет, надо 1-2 нормальных. Которым можно показать мокапы, а они сами
H>выберут фреймворки, компоненты и т.п. Правда как их найти на такие
H>условия — хз.

как я и писал выше схема с наймом опытных сойдет
— либо при наличиии 100К, а не 30К
— либо если эти 1-2 = доверенные "свои" люди
иначе можно жестко нарваться на проблемы

>> 5. в процессе разработки мгновенно писать документацию по всему что делается
H>нет

поправочка
минимальную документацию
которая объясняет неочевидные моменты реализации
о полной речи не идет

Здравствуйте, watcher, Вы писали:

W>б) есть опытный разработчик-проектировщик, который знает как все нужно делать и на что можно напоороться, но сам он уже код писать не будет — только менеджмент и написание бумажек
W>г) human factor у всех игроков в проекте (инвестор, проектировщик, девелоперы) ну просто зашкаливает

хуман фактор у проектировщика, кажется, противоречит его заявленной опытности.

W>так вот, под какие методологии подпадает
W>- начальная части проекта, пока ничего еще не ясно

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

W>- начальная часть второй фазы разработки, пока ничего тоже в принципее не ясно, но есть куча разнонаправленных интересов уже внутри компании

зависит от сроков, бюджета и сложности проекта. и смотря сколько левых людей хочется там кормить.

W>- ну, и третья часть не описанная выше, когда все уже устаканилось и нужно просто тупо идти к цели

методология Х

Здравствуйте, watcher, Вы писали:

W>Здравствуйте, diez_p, Вы писали:

_>>Здравствуйте, watcher, Вы писали:

_>>Мне кажется лучше постараться нанять пару неплохих девелоперов, которые с вменяемым качеством напишут прототип. Предполагаю, что дешевые разработчики из бедных стран напишут такой спагетти код, который убьет проект и если идея окажется успешной, придется все переписывать.
_>>Это избавит вас от тонны спецификаций, девелоперы сами знают компоненты и фреймворки. Кому нужна документация я тож не знаю, обычно ее пишут уже на продукт, пишет девочка за копейки, но ее все равно никто не читает и звонят в саппорт.

W>это слишком дорогое и рискованное решение в условиях ограниченного бюджета и ограниченного набора известных требований

W>но это хороший вариант, если для начала есть 100К$, а не 30K$
Тут надо еще понимать,что дешевые девелоперы напишут прототип. Если он взлетит, то придется написать все заново.

Здравствуйте, watcher, Вы писали:

W>долговременные доаеренные личные отношения между инвесторами и тем человеком, который все начал, выражающиеся в гибкой жирной оплате труда и ненапряжном графике, при котором искать др работу не имеет смысла
W>в идеале должен присутствовать "призрак кнута" и человек, который все начал должен понимать, что если что не так, то его (возможно) подвесят за гениталии
W>как минимум финансово
Ага, ну хоть с живительными расстрелами я угадал))

Если серьёзно: человек, который всё начал, получается, должен быть бывшим разработчиком, разбираться в предметной области, более-менее тимлидом, с офигеннейшей памятью. Плюс он ещё и согласится "провисеть" n месяцев на закрытом проекте. Где вы таких добровольцев берёте???

Пока всё, что я могу сообразить — регионы, ищем любую сайтоклепательную контору и подряжаем на n месяцев (возможно, с условием вхождения части ваших людей в команду). Иначе первый месяц только людей набирать придётся.
Но это такой наивняк получается...

On 26.03.2015 21:48, watcher wrote:

> как я и писал выше схема с наймом опытных сойдет
> — либо при наличиии 100К, а не 30К
> — либо если эти 1-2 = доверенные "свои" люди
> иначе можно жестко нарваться на проблемы
Да, я и имел в виду "доверенных, своих".

>
>>> 5. в процессе разработки мгновенно писать документацию по всему что делается
> H>нет
>
> поправочка
> минимальную документацию
> которая объясняет неочевидные моменты реализации
> о полной речи не идет
По-моему для этого сгодятся и комментарии в коде, отдельные артефакты
вряд ли кто-то будет поддерживать up-to-date.

--
WBR,
Serge.

Здравствуйте, Miroff, Вы писали:

M>Здравствуйте, watcher, Вы писали:

W>>и на основе моего опыта нужно делать так

M>Опыт-то успешный, или как у остальных?

по всякому

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

на практике это может быть смесью "типичного стартапа" с одним из следующего (причем по разному на разных уровнях и на разных этапах)
— новая версия уже имеющегося и давно продающегося продукта
— заказной проект для конкретного заказчика или набора заказчиков
— развлекалово

у меня был специфический экспириенс по всем этим комбинациям, поэтому и мои мысли правильные и ваши

самый главный вывод на будущее
нужно больше думать и больше общаться в самом начале

Здравствуйте, watcher, Вы писали:

W>а какая методология (или набор методологий) работает в таком вот проекте?

Никакая. Проблема в том, что у вас нет "источника правды". То есть и так степень неопределённости высока, а из-за ЧСВ неопределенность будет нарастать еще больше.
Начать нужно с того, чтобы в команде появился менеджер продукта, который знает рынок. Далее он уже составляет беклог.
А по беклогу можно сначала просто по kanban работать, а при масштабировании перейти на скрам.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, watcher, Вы писали:

W>>а какая методология (или набор методологий) работает в таком вот проекте?

G>Никакая. Проблема в том, что у вас нет "источника правды". То есть и так степень неопределённости высока, а из-за ЧСВ неопределенность будет нарастать еще больше.
G>Начать нужно с того, чтобы в команде появился менеджер продукта, который знает рынок. Далее он уже составляет беклог.
G>А по беклогу можно сначала просто по kanban работать, а при масштабировании перейти на скрам.

как термин "источник правды" звучит на английском?
где написано, что любая методология должна базироваться на источнике правды?

Здравствуйте, watcher, Вы писали:

W>как термин "источник правды" звучит на английском?
По разному в зависимости от методологии.

W>где написано, что любая методология должна базироваться на источнике правды?
В agile все опирается на беклог, который ведется одним овнером. В тяжелых методологиях есть srs, то есть спецификация требований, и отдельные роли, которые отвечают за srs. А у нас это обычно называется ТЗ/ЧТЗ.
В любой методологии такой «источник правды» присутствует.

W>на первом этапе
W>на втором этапе
W>на третьем этапе
А когда же начинать продавать? Тут не хватает самого главного этапа — продаж. Или продажи не предполагаются? Просто пилим бюджет инвестора и сваливаем?

W>д) четких требований в принципе нет, а есть "гениальная или псведогениальная" идея от инвестора, куча готовых аналогов в сети, которые частично тупо клонируются
Если у инвестора нет клиентской базы, кому он будет продавать реалтизацию своей гениальной идеи или нет понимания как ее монетизировать, то никакая методология вообще не нужна.

Здравствуйте, watcher, Вы писали:

W>б) есть опытный разработчик-проектировщик, который знает как все нужно делать и на что можно напоороться, но сам он уже код писать не будет — только менеджмент и написание бумажек

На данном проекте, опытный проектировщик — слабое звено. Либо поручите ему писать код (пригодится, как хороший кодер), либо поручите ему работу по другому проекту. Либо увольте, если он не хочет писать код, и для него нет подходящий работы. В нормальной компании всё должно быть подчинено интересам бизнеса. И если в этих интересах нужно писать код (а не разрабатывать громоздкую архитектуру), то квалифицированный разработчик должен это делать без капризов.

W>в) на разработку начальной версии продукта нанимается 1-3 девелопера на несколько месяцев

Неразумное решение. А о людях Вы подумали? Через 3 месяца собираетесь их уволить? Ещё один весомый аргумент, почему проектировщик должен писать код.

W>д) четких требований в принципе нет, а есть "гениальная или псведогениальная" идея от инвестора, куча готовых аналогов в сети, которые частично тупо клонируются

Необходим бизнес-аналитик или продюсер проекта, которые нечёткие требования заказчика может преобразовать в перечень фич и юз-кейсов. Разумеется, этот перечень должен быть согласован с заказчиком и утвержден. Бизнес-аналитик (или продюсер + бизнес-аналитик) — наиболее важное лицо на данном проекте. Это, кстати, ещё одна возможная ниша для проектировщика, если, конечно, у него есть опыт и понимание, как формулировать фичи и писать юз-кейсы.

W>е) а еще есть общий план заключающийся в том, что после того, как начальный бюджет будет использован может быть неожиданный перерыв с финансированием и все девелоперы свалят, но потом можно будет найти много новых денег с помощью разработанного прототипа

Причина, по которой не следует нанимать сотрудников ради этого проекта (во всяком случае, на постоянную работу).