Всем привет! Меня зовут Роман, я руковожу разработкой. Когда-то начинал разработчиком, потом тимлид, сейчас управляю лидами.
В моём багаже опыта — работа в интеграторе, потом в небольшой компании из сферы SMS-маркетинга, череда позиций в in-house разработке в разных отраслях. А сейчас я снова в айтишечке, в заказной разработке.
И вот что забавно: на протяжении всей карьеры меня преследует один и тот же вопрос — как правильно поставить задачу и как отследить реальное состояние разрабатываемой системы.
Казалось бы, инструментов хватает: Jira, YouTrack, Trello, GitLab, Confluence и ещё десятки. Но если копнуть глубже, становится понятно: каждый из них решает только кусочек головоломки. Целостной картины всё равно нет. Она появляется только в голове после погружения, но и тут засада — голов в проекте много, и у каждой своя картинка.
Получается парадокс: мы для других системы строим, а своей нормальной системы у нас всё так же нет. Думаю, многие коллеги узнают себя.
Я выделил пять основных проблем, которые должна решать такая система. Сразу скажу, что америку я не открыл. Хочу разобраться: чего же не хватает для организации разработки без головной боли по поводу тасок.
1. Неоднозначные формулировки задач
Это проблема кажется не истребима. Но снизить болезненный эффект до управляемого уровня можно попытаться. Если грубо, то один из частых вариантов проблемы в том, что в задачах пишут “Сделать модуль загрузки файлов в формате CSV”. Структуры в CSV не описаны, как их интегрировать в текущую системы не понятно. Какие ограничения на размер и время обработки, что делать при возникновении ошибок - все это осталось за кадром.
Обобщенно проблема заключается в том, что все участники думают только о своем: аналитик о функциях, архитектор о компонентах системы, разработчик о чистом коде и контрактах и еще про названия переменных
