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