Открыть список
Как стать автором
Обновить

Черный лебедь в IT-проектах. Взгляд со стороны CEO на проблемы разработки

Управление разработкойУправление проектамиРазвитие стартапаУправление персоналомIT-компании
Из песочницы
Всего голосов 22: ↑20 и ↓2 +18
Просмотры11.7KКомментарии 17

Комментарии 17

На старте у продакт-менеджера появляется мысль, которую он описывает на 2-10 листах


То есть исследование рынка продакт пропускает и полностью забивает на почтенные маркетинговые инструменты, которым скоро уже больше 100 лет?

И даже про Ford Edsel почитать ему не судьба, ему же прыгать, а не думать надо?

Так проблема не в том, что Agile, MVP и Lean в его методологии нет, а в том, что он дурак.

Он и с MVP нужных выводов не сделает.

MVP вроде бы и предназначен для пропуска исследований рынка до старта разработки. Запустили MVP и исследуем прямо на нём

Так да. Один из методов.

Но ведь у описанного продакта даже вопрос так не стоит.

Он и с MVP вопрос так не поставит. Не будет у него пункта «гипотеза неудачна, нужна переоценка».

В нашей компании MVP представляет собой (если по аналогии с автомобилем) высшую комплектацию с сауной, развлекательным центром и распределенной климатической установкой на айпадах.
То есть дальнейшее развитие конечно есть, но это не "развитие" в привычном понимании. Это либо правка ошибок, либо революция.


То есть слова "минимально-возможный для быстрого старта" владелец понимает как-то так. Когда предлагаешь сделать версию хлтя бы без бассейна — отметает категорически. Говорит: "да, в этот раз пусть будет по-твоему, но в MVP будет входить это, это и это. И еще вон то".


И я думаю, таких большинство.

Давно ищу материалы и статистику по влиянию типизации на скорость разработки, не могли бы вы поделиться своими результатами?

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

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

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

Вы не найдете ответа здесь.
Точнее найдете, но он всегда будет "да, конечно, обязательно, без этого никак".

Или наоборот

Наоборот — слишком велик риск получить.

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


Я использовал слово "несколько", но считаю, что точнее оценить не выйдет: нет возможности клонировать людей и заставить их вести два проекта рядом с разным подходом.

какие у вас доказательства?
Перед разработчиками встала задача значительно переделать их идеальное решение. 4 из 5 программистов, имеющих отличные технические навыки и большой опыт в enterprise к этому не готовы морально: крайне неохотно вносят изменения, которые выбиваются из придуманной архитектуры.

О боже, сколько можно пропагандировать это мировоззрение «хороший код vs требования бизнеса»

Классическая ситуация, в которую приходит компания, когда им «нет дела, до идеального кода, надо просто чтобы работало», это:

  • Закостыленный легаси проект
  • Старая команда, которая это писала — ушла, потому что одно дело — писать костыли, и другое дело — поддерживать и развивать проект написанный на костылях
  • Новых хороших разработчиков нанять невозможно — они сходу понимают суть работы, и отказываются
  • Разработка замедляется до уровня «одна фича в пол года»


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

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

Аутсорс как раз хорошая школа для всех, кто считает, что «хард скиллы не важны, важны софт скиллы» — вот там с вами будут вежливо общаться, будут делать только то, что вы захотите (если клиент не просит писать автотесты — их и не пишут), и будут максимально клиенто-ориентированными.

Вот только результатом (на большом отрезке времени) почему-то всегда недовольны…

Найти причины большого числа ошибок в каждой новой версии продукта

Много ошибок может быть только там, где не пишут тесты (или пишут для галочки). А тесты не пишут, когда «быстрей-быстрей, срочно-срочно!» — добро пожаловать в замкнутый круг. Впрочем, ничего удивительного — «Скупой платит трижды»

Внедрение CI/CD даст ускорение на 10-20%

Крупный проект был без настроенного CI/CD? Забавно. А куда смотрел тим-лид? Или компания захотела сэкономить, и взяла тим-лида по цене милда? Ну, в общем, как обычно.

P.S.
На мой взгляд инструкцию можно сократить до двух пунктов:

  • СЕО должен разбираться в разработке. Например, вырасти из программиста. Нет ничего печальнее, чем руководитель разработки, который ничего не понимает в разработке, и может полагаться только на то, что сказал тот или иной «синьер»
  • СЕО должен уметь общаться с владельцами бизнеса. С одной стороны, говоря им правду — что современная разработка, это сложно и дорого, и надо сразу «спуститься с небес и не ожидать чуда», но делать это так, чтобы желание финансировать проект не пропало. Как только СЕО стал соглашаться на неадекватные требования владельцев бизнеса (а они по умолчанию неадекватны — они далеки от разработки также, как луна от земли) — можно закрывать проект.
Перед разработчиками встала задача значительно переделать их идеальное решение. 4 из 5 программистов, имеющих отличные технические навыки и большой опыт в enterprise к этому не готовы морально: крайне неохотно вносят изменения, которые выбиваются из придуманной архитектуры.


Наследование и переделка это противоречащие друг другу вещи. Если используется ООП то проще написать новый проект чем переделывать старый.
Пролистал. На самом деле точек факапа множество, но ключевых можно выделить семь:
  1. Идея изначально была плохой, и рынок ее не принял
  2. Идея была хороша, но в процессе написания ТЗ ее потеряли
  3. Техническая архитектура не соотвествовала в достаточной мере требованиям
  4. Все было отлично, да запороли управление и планирование задачами
  5. Наняли не тех разработчиков — те не справились
  6. Систему не проверили на соответствие требованиям — техническим и функциональным
  7. В процессе эксплуатации не обеспечили нужную надежность, отказоустойчивость и безопасность

Как говорится, выбирайте, кому что больше нравится











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