«Почти всегда есть способ проверить идею без кода»: что нужно знать о разработке продукта в стартапе Статьи редакции

Опыт основателя сообщества разработчиков DOU и сервиса по поиску работы для программистов Djinni Максима Ищенко.

Что я узнал о разработке продукта в стартапе:

1/ Опасайтесь хороших инженеров.

2/ Пока у вас нет product-market fit, у разработки одна задача – проверка гипотез и быстрые итерации. Хорошие инжен…

3/ Фичи зло. Каждая фича – это время на разработку, неизбежные баги, усложнение продукта. Пока нет product-market f…

4/ Лучший код – это код, которого нет. Почти всегда есть способ проверить идею без кода: интервью с пользователями,…

5/ Если можно не нанимать, надо не нанимать. Ваше понимание продукта и пользователей меняется быстрее, чем вы успев…

6/ Все, что можно купить, надо покупать. Емейл рассылки, аналитика, у нас даже была подписка на сервис для загрузки…

7/ Итерации надо делать после релиза, а не до. "Проверка" идей без живых пользователей это самообман.

8/ Everybody lies, включая пользователей. Пользователи говорят то, что по их мнению вы хотите услышать. Мне когда-т…

9/ Еще лучше не спрашивать, а смотреть метрики и что пользователи реально делают в продукте. Это тема для отдельного поста.

10/ Когда я искал бизнес-модель Джинна, пользователи мне говорили, что готовы платить за отправленные сообщения и н…

11/ Для проверки гипотезы с оплатой бонуса я сделал поп-ап для некоторых профилей "начиная общение с этим кандидато…

12/ После нахождения product-market fit нужно разгребать технический долг. Приводить в порядок код, инвестировать в…

13/ Даже самый лучший продукт не взлетит, если о нем никто не знает. Дистрибуция (маркетинг) >> продукта, нельзя об…

14/ End. Предыдущая серия:

0
48 комментариев
Написать комментарий...
Serg Guslyarov

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

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Denis Kiselev

Зря вы так - в подборке известных фактов есть определенная ценность! Даже авторское право защищает сборщиков БД

Ответить
Развернуть ветку
Kirill Pankin
1/ Опасайтесь хороших инженеров.

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

Ответить
Развернуть ветку
Павел Сутырин

Ну вот я такой инженер. Я радостно и незамутнённо, воззрев, внедрял TDD, BDD, Docker, CI, ELK, DevOps, микросервисы, бессерверную архитектуру, impact mapping, в самые неподходящие проекты на самых неподходящих стадиях. Разработчиков проектов было чаще всего... 1.

С Docker-ом я бегал еще во время версии 1.5, kubernetes раскопал когда он еще только вылупился из Гугла, docker cloud разворачивал, когда он еще был tutum.

Сколько реально нужных фич не было выпущено, сколько метрик не собрано, рекламных кампаний сорвано из-за опозданий с релизами? Немеряно.

Психологическое основание: «если все сделать правильно, то всё будет хорошо».
И чем больше знаешь о том, как можно сделать правильно, как сделано «у больших», на которых ты равняешься — тем больше замахиваешься.

Крч, с точки зрения продуктовой разработки — золотые слова.

Ответить
Развернуть ветку
Kirill Pankin

А с чего Вы взяли, что можете называть себя "хорошим инженером"? ;)
Вас же самого смущают результаты. Что же тут "хорошего"?

Ответить
Развернуть ветку
Denis Kiselev

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

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

Так что мы сравниваем мягкое с теплым

Ответить
Развернуть ветку
Илья Куприк

Вы совсем не подходите под хорошего инженера, сорри)) хороший инженер - это не инженер , стремящийся напихать в резюме кучу модных названий , это не инженер который херачит от забора и до обеда kubernetes, docker , ci , tdd ,agile, scrum, data driven Прости Господи . Хороший инженер это инженер который умеет грамотно применить нужные технологии для скорейшего решения конкретных продуктовых зпдач, работая в коллаборации с продуктологами и делая полезные вещи, а не кульные сорян)

Ответить
Развернуть ветку
Denis Kiselev

Не совсем. Грамотно применить - это уже от управления. Это хороший тех директор, возможно, но тут управленческая эрудиция не менее важна чем техническая.

Ответить
Развернуть ветку
Serg Guslyarov

ха, с какого перепуга ты решил что ты хороший инженер?

Ответить
Развернуть ветку
Денис Кулагин
> 1/ Опасайтесь хороших инженеров.

Опасайтесь инженеров с мышлением "крупной компании" — на любой стадии работы над стартапом. Такие люди нужны уже когда компания вырастает из понятия стартап, т.е. когда найден пресловутый product-market fit и нужно закладывать надёжный каркас.

А хороший инженер, это тот, кто может сделать работающую систему из спичек и желудей и с любым количеством ресурсов. Плохой же начнёт сразу крутить велосипеды и всё развалится ещё до MVP.

Ответить
Развернуть ветку
Георгий Хромченко

Фишка в том, что до поиска product/market fit программировать бы вообще надо по минимуму. Это очень сложно было в себе отдирать, но не надо. Надо быстро проверять гипотезы и разговаривать с клиентами, и научиться доставать клиентов

Ответить
Развернуть ветку
Павел Сутырин

Проверять гипотезы, разговаривать с людьми, доставать людей, выбрасывать (о Боже) код — это ж интроверту-программисту-математику... ужас)))

Ответить
Развернуть ветку
Denis Kiselev

Согласен. Хорошие идеи взлетают при сборке даже из говна и палок, зато своевременно

Ответить
Развернуть ветку
Mihail

А я поклонник MVP про который здесь речь.
В тему можно почитать статью (Законы Акина) законы космической инженерии и одно из лучших правил:
40. (Закон Мак-Брайена) Не надо улучшать то что ещё не заработало.

Ответить
Развернуть ветку
Pixel Lens

Со многим согласен, но думаю это всего лишь набор правил, которые сработают в некоторых определенных случаях (пусть даже таких - большинство), а в некоторых не сработают.

Ответить
Развернуть ветку
Джулустан Иванов

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

Ответить
Развернуть ветку
Георгий Хромченко

Эта статья - про стартапы, то есть про проекты, в которых нет доказанной ценности для потребителя и бизнес-модели.

Все что перечислено - это не стартапы.

Ответить
Развернуть ветку
Павел Сутырин

Особенно яркий пример — рабочая группа NASA, отвечающая за космический софт (забыл, как называется). Вот где водопадная инженерия)

Ответить
Развернуть ветку
Евгений Меньшаков

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

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Pixel Lens
Везде баланс нужен.

Аминь. Всё хорошо в меру.

Ответить
Развернуть ветку
Valery Fv

1/ Опасайтесь хороших инженеров.
Ну, нет. Опасайтесь "так себе" инженеров, которые думают, что они хорошие и больше ничего не хотят слышать. Хороший инженер во-первых постоянно думает, что необходимо в проекте, а на чём можно сэкономить время, силы. А во-вторых у него в голове уже на многие проблемы есть хорошие схемы и лучшие практики, которые он точно знает как реализовать. А потому это занимает приемлемое время и потом позволяет легко менять архитектуру под новые фитчи, которые нужно быстро попробовать.

Ответить
Развернуть ветку
Коля Павельев

Какие это "лучшие практики", которые позволяют "легко менять архитектуру"? Очень интересно, расскажите. Единственная "best practice", которая ускоряет разработку - это проект на основе готового и настроенного шаблона, у которого сразу будет хорошая архитектура под однотипные проекты, потому что только хорошая позволяет "легко добавлять фичи", во всех остальных случаях каждая новая фича приводит ко всё большему бардаку и замедлению разработки, и каждому прогрессивному манагеру придётся молиться, чтобы стопорящей оказалась не та фича, которая этот бардак окончательно разрушит за день до финального релиза. Сколько я уже таких проектов и повидал, и наслушался, и навиделся слёз труманагеров. Не одна студия от этого развалилась.
Автор был абсолютно прав, что после нахождения "минимально рабочего прототипа", его код надо сразу же даже не просто привести в порядок, а полностью переписать большую его часть, т.к. на быстрых прототипах продукта не построишь. И так же верно, что люди, делающие прототипы и реальные продукты - абсолютно разные люди даже просто по психотипу.

Ответить
Развернуть ветку
Александр Мазалецкий

Принцип модульности а также такие шаблоны проектирования как Singlton, MVVP, VIPER, MVC, REdux/Flux и другие, которые при правильном и грамотном использовании где нужно, дают хороший способ адаптироваться к изменяемым требованиям, а методики управления проектом, а не говорю про agile, кроме ещё и другие есть.
А вот использование шаблона путь вникуда, прямой проигрыш.

Ответить
Развернуть ветку
Коля Павельев

Господи, ты хоть понимаешь, что всё перечисленное и является частями шаблона поверх фреймворка и просто принципами хорошего прогинга? Это вообще не архитектура конкретного приложения и перегруз начинается не из-за того что ты не разделишь на модель и представление лол. Точнее если этого не сделаешь, то конечно запаришься, но ни один минимально адекватный прогер не будет этим пренебрегать, а фреймворки делают большую часть перечисленного автоматом, речь не об этом вообще. Аналогично с комментариями, тестами итд, о чём написал Valery Fv - всё это просто хорошие подходы, без которых стыдно лезть в дело, но они никак не помогут "легко менять архитектуру", и не помогут даже очень хорошим и умным парням писать нормальные продукты.

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

Есть такая штука: "обратная совместимость версий АПИ". Хз можно ли что-то по теме нагуглить, но те кто апишками занимаются понимают, что это практически чистое воплощение проблем возникающего бардака, о котором я говорю.

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

Можно либо сделать прототип, либо сделать нормальную версию. И даже нормальную версию когда-нибудь придётся переписать. Так происходило со всеми мало-мальски долгоживущими проектами.

> а также такие шаблоны проектирования
> А вот использование шаблона путь вникуда

Лишь бы поспорить.

Ответить
Развернуть ветку
Александр Мазалецкий

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

Ответить
Развернуть ветку
Artem

Что за мода везде Вайпер пихать-то?? Даже в MVP из трёх сцен! Нуёмаё! ;) Чуть речь зашла о структуре, так сразу кто-нибудь да и напишет ;) извините. Наболело.

Ответить
Развернуть ветку
Александр Мазалецкий

Да кто сказал использовать Вайпер в прототипе? Мой ответ на предмет, что любую можно выстроить гибкой, грамотно и правильно примененяя нужны ШАБЛОНЫ ПРОЕКТИРОВАНИЯ. Это не принцип хорошего кода) А ответ к тому, что использование шаблонов тупо кода на том codecanyon, быстро да, дёшево, но с орагнизаццией кода там полная лажа.

Ответить
Развернуть ветку
Artem

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

Ответить
Развернуть ветку
Александр Мазалецкий

Ну, это я в курсе, все ему есть своё место) Вот как раз таких инженеров, кто простые вещи делает сложно и надо опасаться.

Ответить
Развернуть ветку
Anton Matrosov

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

Ответить
Развернуть ветку
Valery Fv

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

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

То, что каждая новая фича у вас приводила к бардаку - ну, извините, такие разработчики на проекте у вас. Фича, безусловно, приводит к удорожанию и усложнению проекта. Но я отказываюсь считать нормальным ситуацию, когда новая фича = бардак.

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

Ответить
Развернуть ветку
Георгий Хромченко

На стадии "поиска product/market fit" рановато иметь команду разработки

Ответить
Развернуть ветку
Павел Сутырин

Во! А что это бы это была за команда? Каковы ее компетенции? А каковы ее инструменты?

Это в преддверии замены собственно программистов интеллектуальными машинами ;)

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Павел Сутырин

Идеальное решение по ТРИЗу — ничего не создано/сделано/добавлено, а проблема решена ;)

Ответить
Развернуть ветку
Александр Мазалецкий

Забавно слышать, что хорошие инженеров думают о тестах, архитектуре и тп. И таких людей ни надо.
Такой дилетантский взгляд хочу сказать. Хороший инженер думают об этом как раз чтобы сократить время разработки, сделать продукт гибким и масштабируемым как раз ко всем фичам, ну и естественно, чтобы отладку и нормальную работу хоть как то можно было гарантировать.
А вот ебашить неповоротливое говнокодище, вот это да, быстро и непонятно что с этим делать, из-за чего сначала легко, а потом не знаешь как простейшие изменения внести, чтобы это не наелось пирогом.
Далее, говорим про маркетинг, но сколько можно считать пользователей сервиса, скопищем идиотом, которые будут работать с прототипом. MVP нормальное сделайте и народ к вам подтянется.
А сделать MVP за меньшие деньги и качественно, если думать головой и хнами, что предлагать своим пртенциональным клиентам.
Большинство стариаперов того, что выше начинаются и начинают лепить все подряд, не понимая, зачем оно вообще нужно, по принципу главное Продать, а потом посмотрим.

Ответить
Развернуть ветку
Георгий Хромченко

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

Ответить
Развернуть ветку
Александр Мазалецкий

Продать можно все, но перед любой разработкою анализ рынка и тп, а не простой идея и пошёл делать.
Лажают как правило не продажи, лажает бизнес модель, люди любят платить за качество и за то что им нужно.
Вот например, нужен нормальный таск менеджер, но есть один но стоит заоблачно, долго ломался, в итоге купил.
Ибо продует качественный, от того и дорогой.

Ответить
Развернуть ветку
Павел Сутырин

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

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

Ответить
Развернуть ветку
Denis Kiselev

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

Наваял из говна и палок - и на рынок. Если взлетело - переписал уже по феншую: TDD/CI, Docker, microservices и прочий DevOps

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Aleks B

я бы сказал: не слушайте тех, кто не делает то же, что и вы

Ответить
Развернуть ветку
Anton Matrosov

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

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Kirill Pankin

хороший инженер == кодер
не хороший инженер == кастдевщик
Так? Или, если не так, то как же?
Какую-же изумительно богатую почву для бесконечной полемики даёт расплывчатое начальное утверждение! А если ещё и в самой полемике использовать расплывчатые понятия (ну, всем же известна чёткая грань между кастдевщиками и кодерами, ага), то беседа обретает невиданные краски! ;)

Ваше мнение выглядит разумно (не считая, опять же, нечёткости определений), но относится исключительно к вашему собственному видению ситуации. Что именно имел в виду Максим из текста можно лишь предполагать.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Max Yankov

Правильный ответ: и то, и другое, в зависимости от приоритетов бизнеса. Хороший инженер должен уметь в оба варианта.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Bogomaz Artem

Вот так появляется вал никому не нужных продуктов со средней функциональностью. Особенно порадовал пост про тестирование, похоже maxua не знает про unit и instrumental тестирование, не говоря уже об a/b тестов

Ответить
Развернуть ветку
Denis Kiselev

Эм. WAT? Какое нафиг unit тестирование на этапе прототипа и пробного выхода на рынок? Тестируют тут не код, а проект на предмет востребованности! Код тут вообще не важен, лишь бы прототип работал.

Вам ровно наоборот говорят: не нужно заморачиваться с полноценным феншуем разработчика пока не ясна востребованность самого продукта! Это стартаперские заморочки, они не про кодинг или инженерию

Ответить
Развернуть ветку
Dmitry Semiriazhko

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

Ответить
Развернуть ветку
Kirill Pankin

.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
45 комментариев
Раскрывать всегда