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