Почему IT-продукты разрабатываются медленнее, чем кажется (или чем могут)
Классика: запланировали релиз на квартал, наняли команду разработки. Через три месяца оказывается, что половина фич не готова, а бюджет потрачен.
Причина не в том, что разработчики плохо работают. Причина в том, что задачи в IT-продуктах идут неравномерно, а штатная модель заточена под постоянную загрузку.
Первый месяц все заняты новым функционалом. Второй месяц нужна API интеграция — один человек работает, остальные в простое. Третий месяц — багфиксы, все руки нужны. А потом требуется DevOps для масштабирования, но такого специалиста в команде нет.
Результат: платите за простои, не можете быстро адаптировать команду под текущие задачи, бюджеты на разработку растут быстрее выручки.
А вот рабочая схема: небольшое ядро в штате (кто ведет продукт и знает архитектуру) + гибкое привлечение специалистов под конкретные спринты. Нужен фронтенд-разработчик на два месяца — подключаете. Требуется усилить команду перед релизом — берете на месяц. Задача закрыта — отпускаете без увольнений. Экономия 40-50% на переменной части команды.
Реализуется через платформу RIWO. Здесь специалисты уже проверены и подбираются именно под ваши требования. Работают по вашим процессам, платите по факту выполненных работ.
Попробовать: riwo.ru
Русский ИТ бизнес 👨
Подписаться
Комментарии (0)
Какой там "взял на месяц".
а основная проблема из-за которой долго все делается - то, что IT-шники бывают склонны к тому, чтобы отвечать строго за свою зону ответственности - типа "я разраб, я не тестировзик" или "я не могу кодить задачу т.к. нет описания" и т.д. и т.п.
а для быстрых запусков нужны люди которые минимизируют "бюрократию" и просто добиваются результата - сами построят архитектуру. сами найдут железо, сами напишут ТЗ на минималках, распланируют работы и сами закодят.
Ну почти "сами" естесственно.. в одиночку редко что можно затащить.
Такие люди кстати - я ))
детальная проработка задачи до того как ее увидел исполнитель, когда описано что и как сделать но не с инженерной точки зрения, а хз вообще с какой. Разработчик берет эту описанную задачу и идет пересогласовывать… А еще хуже, делает как написано… Оба варианта убивают время, первый меньше но сразу, второй аукается еще долго.
Люди действительно не быстро входят в проект, но при этом очен быстро отваливаются те, кто не способен быстро разбираться со сложными проектами.
Экономия существенная по ресурсам.
Более того формируется ядро первого и второго круга.
Тут надо понимать важный момент. Что система управления такими проектами сильно отличается от классической.
Нет у ти лидов которое рулят командами, стендапов и т.д.
Тут очень важна динамика и скорость отклика на любой запрос.
Короче это не для всех:)