«Почти всегда есть способ проверить идею без кода»: что нужно знать о разработке продукта в стартапе
Опыт основателя сообщества разработчиков DOU и сервиса по поиску работы для программистов Djinni Максима Ищенко.
Опыт основателя сообщества разработчиков DOU и сервиса по поиску работы для программистов Djinni Максима Ищенко.
Вы не просто капитан-очевидность, вы прямо таки адмирал - ясен х#й.
Но тем не менее большое вам спасибо, за краткое и емкое изложение.
Комментарий недоступен
Зря вы так - в подборке известных фактов есть определенная ценность! Даже авторское право защищает сборщиков БД
1/ Опасайтесь хороших инженеров.Опасайтесь категоричных утверждений, использующих неясные термины.
Ну вот я такой инженер. Я радостно и незамутнённо, воззрев, внедрял TDD, BDD, Docker, CI, ELK, DevOps, микросервисы, бессерверную архитектуру, impact mapping, в самые неподходящие проекты на самых неподходящих стадиях. Разработчиков проектов было чаще всего... 1.
С Docker-ом я бегал еще во время версии 1.5, kubernetes раскопал когда он еще только вылупился из Гугла, docker cloud разворачивал, когда он еще был tutum.
Сколько реально нужных фич не было выпущено, сколько метрик не собрано, рекламных кампаний сорвано из-за опозданий с релизами? Немеряно.
Психологическое основание: «если все сделать правильно, то всё будет хорошо».
И чем больше знаешь о том, как можно сделать правильно, как сделано «у больших», на которых ты равняешься — тем больше замахиваешься.
Крч, с точки зрения продуктовой разработки — золотые слова.
> 1/ Опасайтесь хороших инженеров.
Опасайтесь инженеров с мышлением "крупной компании" — на любой стадии работы над стартапом. Такие люди нужны уже когда компания вырастает из понятия стартап, т.е. когда найден пресловутый product-market fit и нужно закладывать надёжный каркас.
А хороший инженер, это тот, кто может сделать работающую систему из спичек и желудей и с любым количеством ресурсов. Плохой же начнёт сразу крутить велосипеды и всё развалится ещё до MVP.
Фишка в том, что до поиска product/market fit программировать бы вообще надо по минимуму. Это очень сложно было в себе отдирать, но не надо. Надо быстро проверять гипотезы и разговаривать с клиентами, и научиться доставать клиентов
Согласен. Хорошие идеи взлетают при сборке даже из говна и палок, зато своевременно
А я поклонник MVP про который здесь речь.
В тему можно почитать статью (Законы Акина) законы космической инженерии и одно из лучших правил:
40. (Закон Мак-Брайена) Не надо улучшать то что ещё не заработало.
Со многим согласен, но думаю это всего лишь набор правил, которые сработают в некоторых определенных случаях (пусть даже таких - большинство), а в некоторых не сработают.
Я могу предположить, в каких именно случаях эти правила не сработают - там, где высока цена ошибки: скажем, какой-то медицинский софт, авиация, военная сфера и т. д. В этих случаях контроль за процессом разработки, тестами, релизами и т. д. действительно выходит на первый план. В общем, всегда важен контекст, программирование ведь тоже не сферическое в вакууме.
Да вот часто получается, что без тестов и прочих прихотей от разработчиков, продукт банально начинает сыпаться к определенной итерации. И фичу уже просто так не добавишь, и баги лавинообразно растут. Везде баланс нужен.
Везде баланс нужен.Аминь. Всё хорошо в меру.
1/ Опасайтесь хороших инженеров.
Ну, нет. Опасайтесь "так себе" инженеров, которые думают, что они хорошие и больше ничего не хотят слышать. Хороший инженер во-первых постоянно думает, что необходимо в проекте, а на чём можно сэкономить время, силы. А во-вторых у него в голове уже на многие проблемы есть хорошие схемы и лучшие практики, которые он точно знает как реализовать. А потому это занимает приемлемое время и потом позволяет легко менять архитектуру под новые фитчи, которые нужно быстро попробовать.
Какие это "лучшие практики", которые позволяют "легко менять архитектуру"? Очень интересно, расскажите. Единственная "best practice", которая ускоряет разработку - это проект на основе готового и настроенного шаблона, у которого сразу будет хорошая архитектура под однотипные проекты, потому что только хорошая позволяет "легко добавлять фичи", во всех остальных случаях каждая новая фича приводит ко всё большему бардаку и замедлению разработки, и каждому прогрессивному манагеру придётся молиться, чтобы стопорящей оказалась не та фича, которая этот бардак окончательно разрушит за день до финального релиза. Сколько я уже таких проектов и повидал, и наслушался, и навиделся слёз труманагеров. Не одна студия от этого развалилась.
Автор был абсолютно прав, что после нахождения "минимально рабочего прототипа", его код надо сразу же даже не просто привести в порядок, а полностью переписать большую его часть, т.к. на быстрых прототипах продукта не построишь. И так же верно, что люди, делающие прототипы и реальные продукты - абсолютно разные люди даже просто по психотипу.
Забавно слышать, что хорошие инженеров думают о тестах, архитектуре и тп. И таких людей ни надо.
Такой дилетантский взгляд хочу сказать. Хороший инженер думают об этом как раз чтобы сократить время разработки, сделать продукт гибким и масштабируемым как раз ко всем фичам, ну и естественно, чтобы отладку и нормальную работу хоть как то можно было гарантировать.
А вот ебашить неповоротливое говнокодище, вот это да, быстро и непонятно что с этим делать, из-за чего сначала легко, а потом не знаешь как простейшие изменения внести, чтобы это не наелось пирогом.
Далее, говорим про маркетинг, но сколько можно считать пользователей сервиса, скопищем идиотом, которые будут работать с прототипом. MVP нормальное сделайте и народ к вам подтянется.
А сделать MVP за меньшие деньги и качественно, если думать головой и хнами, что предлагать своим пртенциональным клиентам.
Большинство стариаперов того, что выше начинаются и начинают лепить все подряд, не понимая, зачем оно вообще нужно, по принципу главное Продать, а потом посмотрим.
А вы не поймете что нужно, пока не продадите, все остальное могут быть галлюцинации, и даже 1 месяц разработки на галюны - пустая трата времени.
Категорически на первой версии продукта не нужно заморачиваться качеством кода, архитектурой или любыми шаблонами.
Наваял из говна и палок - и на рынок. Если взлетело - переписал уже по феншую: TDD/CI, Docker, microservices и прочий DevOps
я бы сказал: не слушайте тех, кто не делает то же, что и вы
Ну в общем если грубо, то есть два типа инженеров - прототайперы, и ентерпрайзеры. Я вот больше прототайпер - мне нравится делать небольшие проекты с нуля, в одиночку или небольшой командой, на пересечении сразу нескольких технологий. Делать все очень гибко с самого начала, адаптировать под новые требования, видеть как прототип эволюционирует с каждой новой итерацией. Но в то же время мне скучно дорабатывать уже готовые и давно запущенные проекты. Так что я больше стартаповый разработчик.
хороший инженер == кодер
не хороший инженер == кастдевщик
Так? Или, если не так, то как же?
Какую-же изумительно богатую почву для бесконечной полемики даёт расплывчатое начальное утверждение! А если ещё и в самой полемике использовать расплывчатые понятия (ну, всем же известна чёткая грань между кастдевщиками и кодерами, ага), то беседа обретает невиданные краски! ;)
Ваше мнение выглядит разумно (не считая, опять же, нечёткости определений), но относится исключительно к вашему собственному видению ситуации. Что именно имел в виду Максим из текста можно лишь предполагать.
Правильный ответ: и то, и другое, в зависимости от приоритетов бизнеса. Хороший инженер должен уметь в оба варианта.
Вот так появляется вал никому не нужных продуктов со средней функциональностью. Особенно порадовал пост про тестирование, похоже maxua не знает про unit и instrumental тестирование, не говоря уже об a/b тестов
Эм. WAT? Какое нафиг unit тестирование на этапе прототипа и пробного выхода на рынок? Тестируют тут не код, а проект на предмет востребованности! Код тут вообще не важен, лишь бы прототип работал.
Вам ровно наоборот говорят: не нужно заморачиваться с полноценным феншуем разработчика пока не ясна востребованность самого продукта! Это стартаперские заморочки, они не про кодинг или инженерию
Не поленюсь залогиниться, чтобы сказать, что все в сервисе хорошо, кроме названия. Написать транслитом это слово даже сейчас не смогу.
.