Сначала нужно было выиграть тендер. Для этого нужно было быстро запилить Minimal Valuable Product. И здесь кроется первая ошибка обошедшаяся в приличную сумму для нашего заказчика. Она звучит так: быстро запилить MVP. Заказчик хочет быстро увидеть результат, но это означает что мы жертвуем хорошей инфраструктурой, надежной архитектурой и через год мы пришли к тому что наша Front End архитектура требует серьезного рефакторинга. Порядка нескольких месяцев. Так мы слили 500 000 рублей.
Оглядываясь назад я с уверенностью могу сказать, что первым делом нужно было взять в рассчет весь функционал который заказчик хотел увидеть в конечном итоге через несколько лет. Так мы смогли бы избежать архитектурных ошибок в стиле «данная архитектура этого не предусматривает». В результате каждая крупная фишка требовала серьезного рефакторинга.
Для того чтобы выиграть тендер наша компания послала разработчиков не имевших опыт в проектировании крупных приложений и надежных расширяемых систем. Понятное дело, тендер не заказ, и разбрасываться хорошими кадрами никто не хочет. Но отсутствие технического архитектора на (уровне классов) привела к тому что наше приложение превратилось в спагетти код и перестало удовлетворять требованиям SOLID. И здесь кроется ошибка каждого заказчика. Невозможно поддерживать постоянный темп разработки без увеличения ресурсов команды. Принцип Agile «Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно» работает только вслучае, если с самого начала были известны и проработаны требования, весь набор функционала, спроектирована надежная и расширяемая архитектура (одним словом, если каждый класс продумывался с учетом конечной функциональности системы) и четко поставлены процессы. И это надо было делать в MPV прежде чем пилить продукт. В противном случае, с течением линейного времени сложность приложения растет экспоненциально. Это значит запилить фичу через год будет стоить на O(e(N)) дороже чем в начале.
В нашей команде единственный дизайнер был удаленным сотрудником. Это была серьезная ошибка. Удаленный сотрудник всегда живет своей жизнью. Он рисует себе дизайн, красиво и ладно, заказчик счастлив. Но все эти прелести в конечном итоге сводятся к тому что на одни и те же логические формы у нас присутствует N разных стилей и версток. С самого начала стоило поставить требование: стилизируй определенный фреймфорк (у нас был Ant Design). Если там чего-то нет, делай из того что там есть. Заказчик думал что React это конструктор из кубиков. И он до сих пор не понимает по чему мы по 4 дня пилим примитивные формы. React это конструктор, но только в том случае если у нас в самом начале разработки есть набор однотипных переиспользуемых компонентов (UI фреймворк). Дизайнер без опыта верстки этого никогда не сделает сам. Разработчик никогда об этом не скажет заказчику. За этим должен следить лидер. А значит лидер у Front End команды должен быть Front End разработчком в прошлом, а не Back End как это бывает всегда. Следовательно мы приходим к тому что полнофункциональная команда Agile должна содержать компетентного лидера по каджому из направлений ее работы (FE, BE). Эти лидеры должны обладать сильными Soft скиллами чтобы донести до заказчика то, что я пытаюсь описать в этой статье. А это очень и очень не просто.
Когда мы вышли в первый релиз мы поняли что у нас постоянно что-то ломается в самый последный день перед демо. На протяжении всего года разработки каждая релизная ветка превращается в адский набор костылей (отключи это, убери то) которые потом магическим образом оказываюся в develop ветке. И идет серия коммитов (включи то, включи это). Через год мы пришли к выводу что нам нужно иметь четкую политику ветвлений. Но самое главное, ответственного человека который бы устранил существующий хаос. Это означало: либо умерить хаотичекие желания заказчика, либо умерить хаотические баги, либо на каждом стенде иметь свою конфигурацию отключающие какие-то графические фичи или кнопки. Оборачивать каждую кнопку в if оператор это безумие. Мы пришли к тому что нам нужна фиче-модульная Front End архитектура на базе плагинов (отключи — включи). Я долго думал как достичь подобной архитектуры. Но одно я понял точно. Нам был нужен полноценный контекст. Так зародилась библиотека js-beans (https://www.npmjs.com/package/js-beans). Каждый стенд имел свой json контекст. Плагины собирались в цепочку (чейнились) через паттерн Proxy. Так например, у нас был источник данных как отдельный бин, а различные преобразования делались как опциональные Proxy бины замещающие этот бин, но инжектящие его в себя. Например, если нужно произвести масштабирование модели данных для тестирования FPS производительноси, я просто добавляю в json файл строчку включения плагина масштабирования. Сломалось что-то на продакшне, а локально не воспроизводится, влючаю логгер одной строчкой без пересборки стенда (стенд собирается около 20 минут, да и десятка стендов на всех не всегда хватает). Или если нужно быстро выключить какой-то модуль из-за того что его можно сломать (отключаем опциональный бин в контексте).
Шло время, у нас на неделю отключили стенды. Локально разрабатывать фронт было нельзя. У нас небыло предусмотрено автономной архитектуры на моках. Пришлось через боль со скрипом ее запилить. Сейчас, оглядываясь назад, я бы сделал это в самом начале. Но у нас был MVP, и мы были вынуждены писать код без глубокого проектирования. Но заказчик считал нас профессионалами, и думал что мы должны сразу писать код без ошибок. Здесь следующая ошибка. Имя компании не говорит о профессионализме команды. Профессионализм команды определяется профессионализмом лидера команды. Если технического лидера в команде нет, через год ваш проект зайдет в тупик. Так вы сольете еще парочку миллионов.
У нас был удаленный архитектор. Но о нем было известно только одно: он есть. Последняя стадия развития руководителя по мнению Владимира Тарасова. В этом наш архитектор достиг совершенства. Ошибка номер N: у вас нет технического архитектора, который проектирует систему на уровне классов. У вас нет человека у которого можно попросить помощи если ты пришел в тупик. Обращайтесь за помощью в другие более опытные команды — говорил нам заказчик. Но почему-то в других командах никогда не было времени чтобы нам помочь. Наш ПР висит уже второй месяц. Я искренне надеюсь что найдется храбрый человек который его аппрувнет. В результате жизнь наградила наш код богатым изобилием паранормальных явлений в виде магии и наборов костылей на все случае жизни. Недостовало только одного. Специальных аннотаций Magic и @Kostyle. Хорошая идея для следующего ES.
Мы решили что больше мидлов и меньше синьоров выгоднее для проекта. Сейчас мы думаем иначе. Если у вас маленький бюджет, вам необходимо нанимать самых дорогих специалистов. Если у вас, как у нас, с бюджетом проблем нет, можете смело экономить на специалистах и превратить Code Review в битву экстрасенсов.
Мы думали что мы уложимся в квартальные сроки. Сейчас мы думаем иначе. Короче говоря, по хорошему нам нужно переписать проект. И желательно с нуля. Я надеюсь наш заказчик об этом никогда не узнает. Ведь мы только недавно провели шикарный тимбилдинг)
Мы решили поиграться с новыми технологиями, в которых у нас было мало экспертизы. Нам их порекомендовали. Конечно нам хотелось набраться опыта. Сейчас я думаю, что лучше бы использовал только те технологии, в которых у меня есть опыт.
Мы давали оценки исходя из 8 часового рабочего дня. В реальности, оценки стоит давать исходя из 4х часового рабочего дня. Почему никто не включает чай, рассказ интересных историй, поиск туалета по навигатору, разговор по телефону, переписку, изучение новых технологий и самое главное, увлеченных споров внутри команды. Последнее, наверное, самое неизбежное, и самое накладное. Хотя, если честно, за Open Space нужно еще накидывать пару часов. Постоянные разговоры жутко снижают концентрацию. Блажен заказчик, который все это понимает!
Наши эстимации проходили изнурительно и переходили в нудную техническую полемику как ни крути. Эффективность митингов была минимальной. Но мы нашли решение: вкусная пицца. Когда аппетитный запах раздражает нос человек начинает четче выражать свои мысли.
В начале у нас была одна маленькая команда, потом одна большая команда. Планинг занимал часа 2-3. Стендап 30 минут. За что я уважаю нашего PO, так это за то что он решил разделить ее на много мелких и выделить в каждой из них своего мини PO. Наверное, это было лучшим решением за всю историю нашего проекта.
С самого начала у нас не было времени чтобы писать тесты. Через пол года мы пришли к тому что их все-таки нужно было писать. Но времени на это по прежнему мы не находим. Слишком много более приоритетного технического долга накопилось. Не копить технический долг — это утопия. Он всегда будет.
Мои личные субьективные выводы:
- Если ваши разработчики не понимают для чего нужен IoC на FrontEnd, то скорее всего когда они поймут, будет уже поздно.
- Если ваши разработчики непонимают зачем на FrontEnd нужно знание ООП, то ваш код вряд ли можно будет поддерживать.
- Меньше дорогих специалистов лучше чем больше более выгодных.
- Если у вас есть архитектор, скорее всего вам нужен еще один.
- Если вы пилите MVP, допилите его и смените проект.
- Если до вас уже запилили MVP, не ходите на этот проект.
- Если вы запилили MVP и не хотите уходить, скорее всего вы измените свое мнение.
- Если вы запилили MVP и хотите чтобы ваш проект выжил, перепишите его с нуля.
- Если вы покажете эту статью заказчику, скорее всего вас уволят.
- Если вы работаете по Agile, скорее всего вы меня понимаете.
Вы вряд ли избежите всех этих проблем даже после прочтения этой статьи. Моя цель показать вам, что это неизбежно. И как бы вы не старались, у вас никогда не будет идеальных условий. Поэтому просто будьте к этому готовы. И перед увольнением, можете смело показать эту статью вашему заказчику. Пусть и он будет морально к этому готов.
P.S.: Максим, если ты когда-нибудь прочтешь эту статью, знай, все что я описал полностью вымышленно и не имеет никакого сходства с нашим проектом) Но все это не важно, ведь сегодня я ухожу в отпуск. Первый отпуск за год кропотливой ненормированной работы! (в качестве FE лида).
Комментарии (27)
InterceptorTSK
21.04.2019 20:10На старте автор и его кантора решили, что на этом свете чудеса бывают? Неа, чудес не бывает. И не будет. Никогда не будет. Пишите как положено — тогда заработает. Иначе никак.
И это вам еще повезло, что вы хотя бы что-то написали в итоге, что хотя бы как-то работает. На самом деле, если копнуть поглубже — то у вас и половина написанного не работает, и громко падает при сильно громком чихе. Да, именно так.
И самая главная проблема — на старте у вас архитектора не было. А без него — ничего хорошего никогда не будет. То что у вас в итоге абстракции свелись хотя бы как-то, причем далеко от оптимального — это уже чудо…usego
21.04.2019 21:32+1А такие сферические кони бывают вообще? Что бы изначально многолетний проект сразу спроектировать так, что бы через год ничего не рефакторить? И при этом ТЗ было бы такое, что всё прописано, через год ничего не меняется, заказчик чётко понимает что ему надо, а исполнитель — как этого достигнуть. Имхо такое в стране эльфов только бывает.
InterceptorTSK
21.04.2019 22:11-1Конечно бывают. Про них даже все знают, и вы в том числе. Примеров тому масса. Посмотрите на тот же фреймворк от майкрософта. Неужели вы и вправду думаете, что его кинулись программировать, т.е. раздали задачи и т.д. до того как собрали вменяемую архитектуру? Вы что, правда думаете, что 3000 типов можно скрутить в кучу без предварительного проектирования?) Ну тогда майкрософт и прочие проживают в стране эльфов, не иначе… Ну ладно майкрософт, у них деньги скажете вы) И что с того? А те проекты, которые проектируются максимум десятком человек, и этих проектов действительно много уже — эти тоже имеют финанс как у майкрософта?) Так почему у них все получается в итоге? Может потому, что как раз таки люди изначально понимают что делают, и на чем они это делают, и с привлечением чего? Так такое возможно тогда и только тогда, когда изначально проектируется архитектура, а уже затем по клаве долбят, нет?
usego
22.04.2019 08:19Я с фреймворком начал работать, когда он был в стадии 1.0-beta. Сравните его с текущим .net Core, да и хоть 4.7.2. С тех пор было несколько итераций рефакторинга, причём кардинального, ибо первые версии были спроектированы далеко не идеально, плюс требования менялись во времени.
Но и вообще мой поинт не о продуктах для программеров, а о продуктах для конкретных «реальных» заказчиков. Там чудес с начальным проектированием ещё меньше. Редко, когда заказчик сам понимает, что конкретно ему надо. А при неспособности написать грамотное ТЗ, о каком мегаархитекторе, который заранее всё учтёт вообще говорить можно…InterceptorTSK
22.04.2019 17:12Сравните его с текущим .net Core, да и хоть 4.7.2. С тех пор было несколько итераций рефакторинга, причём кардинального, ибо первые версии были спроектированы далеко не идеально, плюс требования менялись во времени.
Да ничего подобного) Абстракции в общем и целом не изменились. Реализация абстракций конечно поменялась, но реализация абстракций каким образом касается архитектуры?Но и вообще мой поинт не о продуктах для программеров, а о продуктах для конкретных «реальных» заказчиков.
Вы ПО делите на реальное и не реальное? Как это? Фреймворк писался для программистов, и в данном случае заказчики — это программисты. Нет?Редко, когда заказчик сам понимает, что конкретно ему надо.
Такого вообще не бывает. Вы что же, подскажете майкрософту что «вставить» в будущий фреймворк?) И слава тебе хоспаде не подскажете, ибо ну его нафиг, пусть этим вменяемые занимаются, это если по мне.Но и вообще мой поинт не о продуктах для программеров, а о продуктах для конкретных «реальных» заказчиков. Там чудес с начальным проектированием ещё меньше.
А значит и абстракций меньше) Но и эти в общем-то банальные 50 абстракций и 10 базовых типов вы не в состоянии разрулить.А при неспособности написать грамотное ТЗ, о каком мегаархитекторе, который заранее всё учтёт вообще говорить можно…
А вот про это говорилось уже давным давно) Если человек не способен даже «на бумашке» изложить мысли — так это вообще путь вникуда.Редко, когда заказчик сам понимает, что конкретно ему надо.
Так спросите конкретней что заказчику нужно. А как иначе-то? Или снова чудо? Угадывать будете что ему нужно? Ну угадывайте.
Ну и суммарно — что вы написали — не совсем понятно) Ибо что бы вы не писали — суть не изменится. Без вменяемого архитектора никогда ничего не получится. Во всяком случае я таких прецедентов ни разу не видел, что бы на коленке открывшы ВС хоп и скрутили вмиг штук пятьдесят абстракций походя, причем в итоге что бы получилось интуитивно просто и понятно для всех. Вот ни разу не видел.usego
22.04.2019 18:46Вы поработайте ближе к «реальной экономике». Где IT — это не тёплый офис с хипстерами, которые фреймворки пишут, а где программисты — лишь отдел, автоматизирующий реальный бизнес, зарабатывающий деньги на офлайне. Много нового для себя откроете. И про заказчика, с которым достаточно «поговорить», что бы выяснить требования, и про то, что заказчик думает про зажравшихся программистов со всеми их абстракциями и фреймворками.
InterceptorTSK
22.04.2019 20:34Да прекрасно работаю, не переживайте) Не так уж и давно делали проектик для такси. Так вот так называемые умельцы «реальной экономики» ничего толком для канторы и сделать не могли. Все падало, глючило и вообще выглядело как кусок гавна))) Более того, каждый кто принимался писать «следующую» версию сей «шыдевры» — просто отбрасывал все написанное и писал с нуля, представляете? Впрочем я такое вижу почти каждый месяц вообще-то… Так вот, когда было дано вменяемое объяснение, что это дорого, что пишется оно очень долго, что просто так на коленке ничего никогда не получится, и когда все это и то что написано выше было объяснено человеку, и человек был поставлен перед выбором — или парься дальше с гавниной и имей прямые убытки, или все же потрать время и получи дорогой и вменяемый продукт — человек проникся и встал на светлую сторону) Собсна ему и было сделано в итоге все как надо, десять лет назад еще… И до сих пор и далее оно будет работать и проблем с этим не будет вообще, ибо проблемам неоткуда браться. Писалось оно долго, это да, примерно насколько помню чуть более полугода. И что?) У человека выбор что ли есть? Нету.
А вы дальше «обслуживайте» придурков, это уже ваш выбор) Вы же готовы стелиться под любого, кто имеет самые мизерные бабки, не так ли? Ну как неразборчивая шлюха при дороге) Только ни вам, ни клиенту это ничего не даст. И смысл тут в том, что клиенту это ничего не даст — это совсем не беда, а вот то что это вам в итоге ничего не дает — это конкретная беда, но вы к сожалению этого не понимаете. Так и будете хреначить пурген абсолютно никому не нужный и смысла не имеющий) Впрочем это ваш выбор же. После ваших поделок все равно придем мы, и абсолютно неспешно под кофеёк в хипстерском офисе сделаем все по-человечески)))
Zet_Roy
21.04.2019 20:52Что бы на React написать приложение которое тяжело поддерживать это еще нужно постараться.
Вы что набирали людей которые вообще в Reactе не разбираются?jetcar
22.04.2019 09:07да легко, такие же «профессионалы» без архитектора нам на реакте написали, реакт никак не помогает ограничить действия разработчиков тем он и плох, как хочешь так и пишешь, а «best practice» работают только на низком уровне, глобально всё равно нужен архитектор, который продумает общую картину, а не только отдельные кусочки
ZaEzzz
21.04.2019 21:12Вы многое сделали хорошо (хотя думаете иначе), но наступили на достаточное кол-во граблей.
Если коммент наберет достаточное количество плюсов, то отвечу статей. Если нет, то комментарием дальше.ZaEzzz
22.04.2019 09:20+1Не интересно, значит проще без статьи.
И здесь кроется первая ошибка обошедшаяся в приличную сумму для нашего заказчика. Она звучит так: быстро запилить MVP.
Это не первая ошибка. Зачастую это именно верное решение.
Да, нужно понимать, что заранее на будущее нужно заложить время и средства на рефакторинг. Это нормально.
Если бы сразу пилили правильную хорошую надежную инфраструктуру с архитектурой, то ушло бы примерно столько же времени и средств. Почему столько же, а не меньше? Потому что вы еще толком не знаете что конкретно вам потребуется, но заранее будете пилить преждевременную оптимизацию и экономию на спичках.
Ну и вишенкой на торте в данном вопросе — пока вы пилите все сразу правильно, кто-то напишет это быстро и начнет зарабатывать. А потом он наймет вас для того, чтобы все сделать хорошо.
Оглядываясь назад я с уверенностью могу сказать, что первым делом нужно было взять в рассчет весь функционал который заказчик хотел увидеть в конечном итоге через несколько лет.
На самом старте это будет гадание на кофейной гуще. Да, нужно помнить об этом, но не следует прямо усердно закладывать в архитектуру — через год у заказчика легко могут поменяться планы.
Для того чтобы выиграть тендер наша компания послала разработчиков не имевших опыт в проектировании крупных приложений и надежных расширяемых систем.
Да, это не самое лучшее решение. Но вполне жизнеспособное. Кроме того, если бы вы послали архитектора без нужного опыта быстрого старта, то вполне себе вероятно могли бы закопаться в реализации ненужных фич.
Невозможно поддерживать постоянный темп разработки без увеличения ресурсов команды.
Можно, но нужно найти верный сбалансированный темп, а не упарываться на максимальную скорость.
Принцип Agile «Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно» работает только в случае, если с самого начала были известны и проработаны требования, весь набор функционала, спроектирована надежная и расширяемая архитектура (одним словом, если каждый класс продумывался с учетом конечной функциональности системы) и четко поставлены процессы.
В корне неверно. Agile не про это. Легко может все поменяться и это так же нормально. И да, даже в таком случае можно ритм поддерживать бесконечно.
И это надо было делать в MPV прежде чем пилить продукт.
А чем MVP отличается от продукта? Эта фраза не совсем понятна.
В нашей команде единственный дизайнер был удаленным сотрудником. Это была серьезная ошибка. Удаленный сотрудник всегда живет своей жизнью.
Не принципиально. Хоть удаленный, хоть за соседним столом. Вы сами дальше дали ответ что нудно было ограничивать дизайнера.
А значит лидер у Front End команды должен быть Front End разработчком в прошлом, а не Back End как это бывает всегда.
Нет. Обычно бывает, что лидер у фронта или фронт в прошлом, или фуллстек.
Тут вы напоролись на добротные такие грабли.
Agile должна содержать компетентного лидера по каджому из направлений ее работы (FE, BE). Эти лидеры должны обладать сильными Soft скиллами чтобы донести до заказчика то, что я пытаюсь описать в этой статье. А это очень и очень не просто.
Либо одного фуллстека. А с заказчиком лучше говорить ПМ'у, а не тимлиду.
Когда мы вышли в первый релиз мы поняли что у нас постоянно что-то ломается в самый последный день перед демо.
Обычно это происходит когда все или большинство участников, особенно тимлид, раньше были фрилансерами без опыта командной работы.
У нас был удаленный архитектор.
А вот это, в отличии от удаленного дизайнера, очень и очень большая ошибка.
Думаю вы уже поняли, что его у вас не было. Вот он как раз и может на удаленке в своем мирке запилить вообще что-то потустороннее.
Мы решили что больше мидлов и меньше синьоров выгоднее для проекта. Сейчас мы думаем иначе. Если у вас маленький бюджет, вам необходимо нанимать самых дорогих специалистов.
Самый дорогой != подходящий. Нужно нанимать с подходящим опытом.
Мы решили поиграться с новыми технологиями, в которых у нас было мало экспертизы. Нам их порекомендовали. Конечно нам хотелось набраться опыта. Сейчас я думаю, что лучше бы использовал только те технологии, в которых у меня есть опыт.
Верный вывод. Играть с новыми технологиями нужно тогда, когда есть время, деньги и потребность.
Да, обучение — это так же потребность.
Наши эстимации проходили изнурительно и переходили в нудную техническую полемику как ни крути. Эффективность митингов была минимальной.
Просто дробите до состояния «это я точно успею за 4 часа» и без зарывания с технические подробности.
За что я уважаю нашего PO, так это за то что он решил разделить ее на много мелких и выделить в каждой из них своего мини PO.
Если вас много, то без Scrum on Scrum и подобных техник уже не обойтись.
С самого начала у нас не было времени чтобы писать тесты. Через пол года мы пришли к тому что их все-таки нужно было писать.
Можно в самом начале не писать много тестов. Главное научиться писать правильные тесты в минимальном количестве — хотя бы с этого начать.
Я очень часто встречаю людей, которые умеют писать тесты и пишут их, но сами тесты особого профита не дают.
Не копить технический долг — это утопия. Он всегда будет.
Требуется соблюдать баланс. Берите на спринты задачи из типов: фича, баг, рефакторинг и «ну это надо когда-нибудь сделать».
Задачи последнего типа будут первым делом выкидываться из спринта, если вам прилетит что-то срочное. А если не прилетит, то вы наконец-то это сделаете.
Если ваши разработчики непонимают зачем на FrontEnd нужно знание ООП, то ваш код вряд ли можно будет поддерживать.
То вам не нужны такие разработчики.
Если у вас есть архитектор, скорее всего вам нужен еще один.
То проверьте, что у вас действительно есть архитектор.
virtualsys
21.04.2019 21:18Ничего страшного. Со временем придет понимание как «Как
не слитьосвоить 10 миллионов бюджета вашего заказчика играясь с Agile». Это — вершина мастерства.
gleb_kudr
21.04.2019 21:25При чем здесь agile и реакт? Любой проект можно зафакапить с любыми методологиями и технологиями.
virtualsys
21.04.2019 21:38+1Ну, в данном случае, кмк Agile это просто заклинание, которое даже не использовали в соответствии с теорией итерационных моделей. Там, как минимум, подразумевается компетентность всех участников+проектирование от общей концепции к частностям+тестирование. Додуматься до проектирования некоего прототипа в начале, реализовать детали, не тестировать это, а потом обдумывать, верно ли мы выбрали направление — ну это что угодно, но не Agile.
Ну, если только рассматривать это слово как синоним анархии.
AdvanTiSS
21.04.2019 21:43+2С чего вы взяли, что MVP предполагает создание первой версии продукта из говна и палок? Это было одной из ключевых ошибок. MVP это не прототип, а полноценное архитектурно сформулированное решение но с минимальным функционалом.
JustDont
21.04.2019 23:19Очень поддерживаю. MVP — это вертикальный срез с абсолютным минимумом фич. Внутренне он при этом должен быть такой, чтоб в дальнейшем вырасти до поддержки всех фич без костылей и подпорок. Если внутренне MVP такой, что «лишь бы демо работало» — это не MVP. Это демо-обманка для заказчика.
zviryatko
22.04.2019 01:26Не соглашусь с вами, mvp это минимально жизнеспособный Продукт, вы продуктом называете только написанный вами код, но чаще всего код сам по себе никому не нужен, а нужна ценность. Например, вы хотите зарабатывать деньги на сайте с хорошим уникальным контентом, и для mvp вы просто выберете сайт на wordpress, а когда вы поймете что это то чем стоит дальше заниматься, то перепишете всё на какой-нибудь современный и модный язык. Когда-то давно сайт «Цукерберг позвонит» был на wordpress, и ничего, переписали же. Но это если вы не знаете выстрелит ли идея или нет. Есть иная ситуация, когда у вас есть какой-то бизнес, например вы продаете что-то, и вам нужен свой интернет магазин, и понимаете что у вас он будет так или иначе и есть запас по времени и бюджету, тогда можно себе позволить сделать mvp с твердой основой, именно срезом по функциям и показать какой-то начальный функционал. Вообще ни в той ни в другой ситуации вы не застрахованы от того чтобы выбросить mvp и воспользоваться готовым решением или вообще сменить направление бизнеса.
JustDont
22.04.2019 12:34а нужна ценность
Это именно то, что вкладывается в «абсолютный минимум фич». Минимум — такой объем, при котором проявляется ценность продукта.
Например, вы хотите зарабатывать деньги на сайте с хорошим уникальным контентом, и для mvp вы просто выберете сайт на wordpress, а когда вы поймете что это то чем стоит дальше заниматься, то перепишете всё на какой-нибудь современный и модный язык.
Как это противоречит тому, что написал я?
Если в архитектуру заранее заложено «вордпресс — временный выбор», то всё в порядке. Например, вы не будете делать действий, которые вас слишком сильно привяжут конкретно к вордпрессу.zviryatko
22.04.2019 18:08Я скорее говорил об этом:
это не MVP. Это демо-обманка для заказчика.
Иногда это вполне себе MVP.
zviryatko
22.04.2019 01:04Прошу прощения, но у вас не scrum команда, и никаких лидов со знанием бекенда и фронтенда вам не нужно, есть лид команды (который team lead) иногда ему можно вообще не разбираться в коде, если умеет думать, а есть ведущий технический специалист, который разбирается лучше всех в каком-то своем направлении (или по всем направлениям, что встречается не так редко), не нужно путать этих двоих, т.к. первый обычно отправляет вас ко второму в случае вопросов. Это то что касается команды, а вот на счёт процессов то если вам как лиду приходится разбираться с планированием ресурсов, то ваш ПО не тянет, в скрам командах не нужны лиды, и менеджеры тоже не нужны, когда они появляются значит вы пытаетесь прикрыть какую-то проблему.
По поводу мвп полностью вас поддерживаю, у такого проекта одна цель (в вашем случае это концепт для получения тендера) а следующая цель уже другая, а именно главная задача которую решает ваш проект. Если это какой-то небольшой или статичный проект, то мвп может иметь продолжение, например система инвентаризации в небольшом офисе, как мвп использовали Гугл таблицы + qr коды, а дальше просто добавили все необходимое и этого было достаточно, т.е. у проекта не появилось кучу требований в процессе. А если проект динамичный и ещё не всё понятно как будет, тогда вам в помощь agile (и лучше закажите тренера) и мвп скорее всего придется выбросить, т.к. у этих двух проектов разная цель.
Проблемы которые вы описали очень типичные (приблизительно 2/3 ИТ проектов проваливаются), и должны решаться командой, а не одним человеком.
Кстати технический долг можно исправлять либо сразу весь либо постепенно, мне нравится второй вариант, т.к. это происходит более контролированно. И скрам в этом отлично помогает, особенно если ваш ПО знает что от него требуется.
Всяческих успехов вам в нашей нелегкой профессии ;)
iliasm
22.04.2019 06:50Хорошо, что ошибки написали, а вот выводы, мне кажется, не очень получились взвешенные, может стоило после отпуска.
MVP — прототип или не прототип, бывает по-разному, на очень больших или очень непонятных проектах я бы сказал что вполне может быть прототипом, который на выброс на 80-90%.
MVP`ить можно и вотерфоллом, кидать все камни в огород Agile не надо.
По-моему основная проблема кроется в том, что проект некому было грамотно вести, не хватило пары опытных людей чтобы вытянуть.
Не понравилось про смену проекта после MVP, наоборот же, кому лучше продолжать как не тому, кто этот MVP делал, он как раз набил все шишки, новому человеку надо будет вникать заново с рисками переписать MVP, а не написать базу для уже рабочего продукта, наверное, наболело, но встречал я людей любящих делать MVP и убегать, неприятно с ними.
mad_nazgul
22.04.2019 07:23Нет отрицательного результата, есть обратная связь!
Так что у вас есть опыт. :-)
Scf
22.04.2019 10:10Хорошая статья, прямо светлое пятно бесценного собственного негативного опыта на фоне переводных новостей и рекламных постов.
Моё мнение о причинах и как этого избежать:
- MVP лучше назвать прототипом и выкинуть сразу после получения контракта. Для ускорения процесса и устранения желания сэкономить, взяв прототип в основу проекта, лучше писать прототип на отдельном языке и технологии для быстрой разработки. рельсах, ангуляре, реакт+js тяп-ляп без стора.
- толпа миддлов должна компенсироваться активным архитектором и жестко поставленным процессом разработки. Включая ревью всех коммитов, автоформаттеры, требования к коду и тестам и т.п.
- Команда не должна пермаментно делать больше функционала, чем она может делать, иначе качество кода закономерно падает. Защищать команду от заказчиков — обязанность тимлида с PM, похоже, они не справились.
measurementinvest
22.04.2019 11:09+1Выдохните и наберитесь эмоционального интеллекта. Может вы станете лучшим разработчиком MVP когда сделаете рациональные выводы. И поймёте важность выбора всего от заказчика, до членов команды, инструментов и системы взаимодействия. Затем посмотрите на проект со стороны и подумаете насколько важно спроектировать MVP и конечную цель, создать пошаговый план и адекватное ТЗ и будете следовать ему.
Это как первый блин на сковородке- представьте если бы все люди в мире сдавались перед его величием. Успехов
Anton23
Статья напоминает мысли капитана очевидности.
Особенно это: