Материал подготовлен на основе выступления Фионы Фунг (Fiona Fung), главного инженера команды Claude Code. Ссылка на публикацию.
Сегодня я наткнулся на кое-что, что показалось мне весьма ценным.
Это довольно редко встречается — AI-компании вроде Claude действительно делятся мыслями и размышлениями об организационной структуре.
Сколько людей - столько и мнений о процессах в команде (с).
Давайте поразмышляем - как выстроить процесс анализа так, чтобы он стал для команды не формальным набором этапов, а рабочим инструментом? Опираемся на наш опыт работы в командах разработки одного из операторов электронного документооборота. Все описанные процессы формировались и развивались на практике.
За отправную точку возьмем несколько потребностей:
управлять неопределённостью,
повышать качество требований,
снижать риски на этапе разработки.
Всем привет! Я системный аналитик в компании «СИБИНТЕК-СОФТ». Последние несколько лет занимаюсь разработкой ИТ-продуктов и сталкиваюсь с одной и той же проблемой – документация есть, но ее не читают. В чём причина — в лени разработчиков или в плохо написанной документации? Давайте разберёмся.
Важно: речь в статье идёт именно о внутренней технической документации для команды разработки: архитектурных решениях, описании сервисов, API и т.д. Это не про инструкции пользователей или администраторов и не про проектную документацию для заказчика.
В какой-то момент почти каждая продуктовая IT-команда приходит к одной и той же мысли: «Нам нужно навести порядок в процессах».
Это обычно происходит не из-за моды на менеджмент, а из-за вполне конкретных ощущений:
задач много и все срочные
задачи делаются дольше, чем хотелось бы
ожидания у команды и бизнеса не совпадают
обсуждений много, а ясности нет.
В такие моменты «описание процессов» начинает казаться логичным решением. Если всё расписать, разложить по шагам, назначить роли и ответственных - вот тогда заживем!
Мы, кажется, пробили новое дно.
И что особенно удивительно, Карл! – аккуратно, без паники, с хорошей формулировкой и абзацами.
Я сначала не понял, что стало происходить. Было ощущение странного дежавю: читаю change request или баг-репорт, киваю, вроде всё логично... но что-то не так, как будто где это уже читал. Слова правильные. Причинно-следственные связи на месте. Термины употреблены верно. Пытаюсь понять в чём проблема – ноль. Как будто читаешь инструкцию к микроволновке, а не описание реальной проблемы. Пытаюсь прочитать ещё раз и ещё раз - с трудом продираюсь через текст с каким-то смутным понимаем того, что написано.
В разных командах разработки наблюдается похожая картина. После внедрения ИИ в процессы он ускоряет не только работу, но и масштабирует уже существующие проблемы.
Мне приходилось внедрять ИИ в продакшн-среду в разных доменах — от классических моделей классификации до разворачивания собственных серверов под локальные LLM и интеграции генеративных моделей для усиления командной работы. В каждом случае вывод оказывался одинаковым.
Эта статья будет полезна как разработчикам, так и менеджерам. Если вы представляете большую компанию с неограниченным бюджетом, возможно, она вам не пригодится.
В погоне за продуктивностью часто создаются «гибкие» системы, гибкость которых на деле оказывается иллюзорной. В результате возникают простои, необходимость переделывать свеженаписанный код, а также искать и исправлять баги. При этом такие системы не освобождают нас от необходимости оставлять после себя структурированные артефакты в виде верхнеуровневой документации.
Представьте, что вы - руководитель команды разработки в IT-компании. Живете себе спокойно, никого не трогаете, делаете с командой проекты, закрываете задачи. И вот в какой-то момент к вам приходит ваш непосредственный руководитель и спрашивает вас:
Слушай, а твоя команда вообще производительна?
И тут вы понимаете, что вопрос застал вас врасплох. В вашей голове запускается мыслительный процесс:
Был ли у вас хоть раз в жизни подобный диалог с начальником или тимлидом?
Тимлид: {name}, за сколько времени сделаешь эту задачу? За неделю успеешь?
Я: Да. Может быть, чуть больше — ещё тестами надо покрыть. Дней десять, наверное.
В итоге вы делаете задачу месяц.
У меня такое случалось не раз. И я всегда восхищался людьми, которые могут сразу сказать: «Какая неделя? Здесь работы минимум на месяц».
