Влияет ли техстек на эффективность разработки?
Я более 25 лет занимаюсь разработкой и за это время успел попробовать десяток разных языков программирования и еще десяток понаблюдал близко.
Возьмем, к примеру, такой довольно стандартный проект, как интернет-магазин и такую стандартную задачу - добавление платежной системы для оплаты покупателем. У нее есть стандартные этапы по внедрению:
- Постановка задачи
- Расписывание технического исполнения
- Непосредственная реализация технического исполнения
- Написание unit тестов
- Code-review
- Приемное тестирование задачи на staging(dev) сервере
- Приемное тестирование задачи на production сервере
И по моим наблюдениям(на очень многих проектах и разной степени квалификации исполнителей), исполнение данного списка задач не сильно зависит от того, на каком техническом стэке и языке его выполняют, так как бизнес-логика по сути примерно одинакова. Ну то есть более сложные платформы типа Java добавят свои 20-30% ко времени реализации, но в целом картину сильно не меняют.
Более того, ни один подход к разработке - Agile, Scrum, XP, парное программирование, практически никак не сократят время на исполнение задачи.Как же добиться существенного сокращения времени исполнения задачи?Вот реально работающие методы, которые я лично наблюдал:
- Сокращение шагов по внедрению. На самом деле, тесты и code review - первое, что может пойти под нож, если исполнитель достаточно квалифицирован и опытен. Тестирование задачи на production тоже некоторые компании исключают(юзеры - наши лучшие тестеры) и в некотором плане это действительно работает.
- Упрощение самой задачи. Меньше функционала => меньше кодить => меньше тестировать => меньше вероятность ошибки. Казалось бы, простая логическая цепочка, но очень многие усложняют задачи без особых на то причин.
- Задачу, по возможности, должен выполнять один человек. Даже простое разделение задачи на backend и frontend разработчиков может в разы увеличить время исполнения. А причины простые - разработчиков нужно синхронизировать по времени, часто будет перекладывание ответственности и недовольство, взаимное недопонимание(усложняемое удаленкой).
- От всех разработчиков нужно добиваться ответственной разработки - чтобы весь код после передачи на приемное тестирование не содержал лишнего, был готов к production, а задача была достаточно протестирована непосредственно самим разработчиком. Часто наблюдал такую картину - разработчик, чтобы показать скорость, коммитит сырой код - не все корректно работает, видны небрежности и отладочные куски кода. Естественно, задача заворачивается обратно code-reviewer’ом или тестером-приемщиком. И так порой несколько раз. В итоге задача значительно растягивается по времени - недели или даже месяцы.
- Более продуманная поставновка задачи и более тщательное описание технической реализации сильно экономят итерации «сделали - посмотрели - увидели, что не то - отдали на переделку».
В качестве вывода:
Сам технический стек не так сильно влияет на эффективность решения задач(ну кроме случаев, когда очень неудачно подобран). В то время как грамотно налаженные процессы, ответственные и мотивированные сотрудники - это ключевые компоненты эффективности команды.
Причины задержек на работе надо искать в организации труда, методах управления и корпоративной культуре. Мы изучили, как устроены процессы в разных компаниях, выяснили, в чём проблема, и нашли способ победить сверхурочные.
Международная ассоциация управления проектами IPMA (да, такая существует с 1965 года в Цюрихе, я сама в шоке) провела исследования, согласно которым использование современных инструментов проектного менеджмента экономит 20-30% временных ресурсов и 15-20% финансовых. Не смотря на явную заинтересованность ассоциации в результатах, цифры мне видятся с…
Задумайтесь: все ли задачи, которые вы ставите сотрудникам, выполняются в полной мере и ведут к их профессиональному росту? Или некоторые делаются спустя рукава, и команда не развивается (или почти не развивается)? Растить крутых специалистов, которые двигают компанию к целям, в ваших же интересах. Так что сегодня разбираемся, как эффективно ставит…
А еще — отказываемся от разработки, если приложение нужно «потому что у всех есть». Рассказываем о нашем подходе — с метриками, маркетинговым анализом и оценкой, нужен ли вообще ИТ-продукт
У меня нет способности к изучению языков, но я даже и подумать не мог что это распространяется и на языки программирования, очень завидую, благо по доброму, тем людям которым это легко дается.
Класс!