Comments 17
MVP вроде бы и предназначен для пропуска исследований рынка до старта разработки. Запустили MVP и исследуем прямо на нём
В нашей компании MVP представляет собой (если по аналогии с автомобилем) высшую комплектацию с сауной, развлекательным центром и распределенной климатической установкой на айпадах.
То есть дальнейшее развитие конечно есть, но это не "развитие" в привычном понимании. Это либо правка ошибок, либо революция.
То есть слова "минимально-возможный для быстрого старта" владелец понимает как-то так. Когда предлагаешь сделать версию хлтя бы без бассейна — отметает категорически. Говорит: "да, в этот раз пусть будет по-твоему, но в MVP будет входить это, это и это. И еще вон то".
И я думаю, таких большинство.
Давно ищу материалы и статистику по влиянию типизации на скорость разработки, не могли бы вы поделиться своими результатами?
Согласен, типизация снимает ряд ошибок связанных с типами, но в тоже время добавляет дополнительной сложности. Необходимо добавлять классы обертки, маппить классы и тд. Если у вас сохранились данные по работе команды (запуск фич, исправление багов и тд) было бы здорово на них посмотреть.
Так вот как раз интересно, как время, затраченное на написание и поддержку типов, соотносится с количеством и "качеством" багов, за какой срок инвестиции в типы окупаются и окупаются ли
Перед разработчиками встала задача значительно переделать их идеальное решение. 4 из 5 программистов, имеющих отличные технические навыки и большой опыт в enterprise к этому не готовы морально: крайне неохотно вносят изменения, которые выбиваются из придуманной архитектуры.
О боже, сколько можно пропагандировать это мировоззрение «хороший код vs требования бизнеса»
Классическая ситуация, в которую приходит компания, когда им «нет дела, до идеального кода, надо просто чтобы работало», это:
- Закостыленный легаси проект
- Старая команда, которая это писала — ушла, потому что одно дело — писать костыли, и другое дело — поддерживать и развивать проект написанный на костылях
- Новых хороших разработчиков нанять невозможно — они сходу понимают суть работы, и отказываются
- Разработка замедляется до уровня «одна фича в пол года»
Подбор команды — большая тема для отдельной статьи. Простое решение — воспользоваться услугами компаний, которые специализируется на запуске IT-проектов и смогут подобрать вам команду из необычных программистов, которые каждую новую версию делают профессионально, но при этом готовы к большим переделкам, так как запустили уже более десятка проектов.
Аутсорс — это самое дно разработки. Если уж советуете аутсорс как простое решение — добавляйте, что сразу нужно закладывать, что это будет прототип, который можно будет запустить, проверить метрики и интерес аудитории, а потом, в случае успеха — нужно будет писать проект нормально, с нуля.
Аутсорс как раз хорошая школа для всех, кто считает, что «хард скиллы не важны, важны софт скиллы» — вот там с вами будут вежливо общаться, будут делать только то, что вы захотите (если клиент не просит писать автотесты — их и не пишут), и будут максимально клиенто-ориентированными.
Вот только результатом (на большом отрезке времени) почему-то всегда недовольны…
Найти причины большого числа ошибок в каждой новой версии продукта
Много ошибок может быть только там, где не пишут тесты (или пишут для галочки). А тесты не пишут, когда «быстрей-быстрей, срочно-срочно!» — добро пожаловать в замкнутый круг. Впрочем, ничего удивительного — «Скупой платит трижды»
Внедрение CI/CD даст ускорение на 10-20%
Крупный проект был без настроенного CI/CD? Забавно. А куда смотрел тим-лид? Или компания захотела сэкономить, и взяла тим-лида по цене милда? Ну, в общем, как обычно.
P.S.
На мой взгляд инструкцию можно сократить до двух пунктов:
- СЕО должен разбираться в разработке. Например, вырасти из программиста. Нет ничего печальнее, чем руководитель разработки, который ничего не понимает в разработке, и может полагаться только на то, что сказал тот или иной «синьер»
- СЕО должен уметь общаться с владельцами бизнеса. С одной стороны, говоря им правду — что современная разработка, это сложно и дорого, и надо сразу «спуститься с небес и не ожидать чуда», но делать это так, чтобы желание финансировать проект не пропало. Как только СЕО стал соглашаться на неадекватные требования владельцев бизнеса (а они по умолчанию неадекватны — они далеки от разработки также, как луна от земли) — можно закрывать проект.
Перед разработчиками встала задача значительно переделать их идеальное решение. 4 из 5 программистов, имеющих отличные технические навыки и большой опыт в enterprise к этому не готовы морально: крайне неохотно вносят изменения, которые выбиваются из придуманной архитектуры.
Наследование и переделка это противоречащие друг другу вещи. Если используется ООП то проще написать новый проект чем переделывать старый.
А ведь продукт может быть уже действующий и MVP — это новый функционал/версия/рынок, который пытаются реализовать старой командой.
Тут как раз и расцветают описанные в статье проблемы, и становится понятно зачем аудит. Ведь выстроившие процесс руководители, под грузом операционки, не могут найти время и ресурс для рефлексии и объективной перестройки процессов, особенно если необходимо признать потерб контроля.
Черный лебедь в IT-проектах. Взгляд со стороны CEO на проблемы разработки