Комментарии 20
Долго получилось, напишу сильно короче – на выходе получится сломанный процесс.
Работа с требованиями это взвешенная аналитика, которая требует глубокого функционального и технического знания проекта от проектировщика, поэтому этот человек должен быть конечным архитектором решения. Поэтому даже писать такой документ человек не занимающийся технической реализации (в статье выше, тимлид) не может по определению.
Итого, если я всё правильно понял из статьи, получается сломанный процесс, когда тимлид "сделал" требования, раскидал по техлидам, а те завернут эти требования и отправят обратно на доработку, и получится несколько циклов согласования. Зачем?
Я предполагаю что "тимлид" и "техлид" пришлось разделить чтобы не перегружать обычный тимлидов. Это решается иначе. Просто дробите команды сильнее, делайте больше тимлидов, и нормируйте нагрузку между ними.
Важно, чтобы тимлид «говорил» с системными-аналитиками на одном языке. В нашем курсе для тимлидов есть урок про техническую документацию и системную аналитику. На уроке мы разбираемся с требованиями, артефактами и графическими нотациями описания требований и бизнес-процессов.
Системный аналитик не может описать полноценные требования, он не знает глубоких технических деталей, поэтому все аналитики работают тесно с архитекторами, и только последние могут дать добро на документ, иначе это будет сломанный телефон, требования напишут одни, а на самом деле техническая реализация (или даже бизнес требования) должна быть другая.
Поэтому тимлид будучи не архитектором (по статье выше) нормально проверить точность требований не может, он допустит ошибки, которые потом будет выгребать за него техлиды.
Поэтому это сломанный телефон и лишнее звено в виде тимлида.
>Важно, чтобы тимлид «говорил» с системными-аналитиками на одном языке. В нашем курсе для тимлидов есть урок про техническую документацию и системную аналитику. На уроке мы разбираемся с требованиями, артефактами и графическими нотациями описания требований и бизнес-процессов.
Вот, это и называется попытка натянуть сову на глобус J
Вы взяли нормального лида, распилили на две должности, получили сломанный процесс, проблемы с обработкой требований, и вместо того чтобы задачей требований занимался конечный архитектор, вы пытаетесь научить всех (аналитика, тимлида, техлида) говорить на одном языке, т.е. вы пытаетесь починить этот "сломанный телефон". Браво J
Тимлиду важно читать то, что приходит от аналитиков, тимлиду и всей команде – вот это я называю «говорить на одном языке».
Да, тимлид может допустить ошибку, важно минимизировать эти ошибки и у тимлида есть для этого все возможности. Важно понимать, что именно тимлид отвечает за техническое качество проекта и может делегировать команде (техлиду, архитектуру, QA и т.д.) задачи, а не свою ответственность.
Тимлид у вас получится каким-то бюрократом, раздающим задания. А техлид - прорабом.
+1 к сломанному процессу. Не надо так.
Тимлид делегируем задачи, а не ответственность. Если процесс cломается, тимлид пофиксит :)
… операционные и бизнес-процессы.
Не понял эту фразу. Бизнес-процессы по определению «операционные», — как альтернатива проектным процессам – процессам с CAPEX составляющей.
Тимлид, управляющий процессами, коммуникациями и бюджетом.
А руководитель проекта, что должен в этот момент делать?)
У нас в команде техлид и тимлид работают в паре.
Тимлид драйвит команду, ведет встречи, общается с заказчиком по вопросам, которые затрагивают будущее развитие проекта, консультирует другие команды, снимает с аналитиков нагрузку в части документирования архитектурных решений (по задачам аналитики веду доку самостоятельно).
Техлид общается с архитектором и другими техлидами (проект большой, команд много) по вопросам техдолга, дефектов и развития системы, готовит шаблоны сервисов, консультирует где и какую информацию и доступы получить. Ну и код пишет, конечно.
В паре получается миникоманда внутри команды, которая разруливает какие-то вопросы, чтобы остальным работалось комфортно и весело.
Во многих больших проектах есть ещё и архитестор. И тогда за архитектуру отвечает он.
Как уже только менеджеров не называли.
Техлид – старший разработчик, готовый брать на себя больше ответственности.
Можно подробнее про вертикальное и горизонтальное масштабирование компетенций, разницу между ними, и почему горизонтальный тип может стать тим лидом, но вряд ли тех лидом. Я конечно интуитивно понимаю, но хотел бы знать точно.
Без тимлида не обойтись, а что насчет техлида?