How to become an author
Search
Write a publication
Pull to refresh

Comments 15

Правильный тимлид в разработке — это как сержант в армии США. А сержантский корпус — становой хребет армии США.
Total votes 7: ↑7 and ↓0+7
Тимлид в разработке — как Team Leader в морской пехоте США )))
This comment wasn’t rated yet0
Пишет ли тимлид код? Безусловно

хм… Почему? («потому что вдохновляет команду»? что за бред?)
Total votes 3: ↑1 and ↓2-1
Владимир, простите за прямолинейность, так-то я редко высказываюсь, но вы реально написали какую-то хрень. Мне вот сразу видно, что знания у вас чисто теоретические, и на практике вы никогда не строили команду разработки и понятия не имеете, кто там за что отвечает. Если увижу в резюме кандидатов название вашей школы — ну точно не возьму такого на работу.
Total votes 11: ↑5 and ↓6-1
Всегда доставляли такие комментарии. Появился из неоткуда сказал, что материал «хрень» без всяческих оснований, получил лайки. Я бы не отказался прочитать ответную статью, чтобы подкрепить сказанное. В противном случае, ценности от коммента ноль.
Total votes 8: ↑6 and ↓2+4
Евгений, это, безусловно, ваше право и я не претендую на соответствие конкретно вашим ожиданиям — я поделился своим мнением, хотя меня всегда настораживали люди, способные делать поверхностные выводы на основании недостатка данных. Надеюсь, это помогает вам в работе.
Total votes 2: ↑1 and ↓10
снятие запроса клиента
и
планирование и выпуск релизов

Это вот уж точно не зона ответственности тимлида. Преобразовывать требования клиента в понятный список требований — это, как правило, задача либо бизнес-аналитика, либо менеджера проекта. А планирование релизов это вообще стратегическая задача. Тимлид отвечает чаще всего за тактику: разбить список требований на итерации, выделить задачи, проводить ревью кода, и держать в тонусе команду не давая ей прокрастинировать и еще не мало всяких вещей. Однако нужно понимать, что основная область работы тимлида — это его команда, он отвечает за общую эффективность.
А то, что вы поместили в обязанности некоего менеджера. То это административные задачи в широком смысле, которые зачастую вообще имеют мало отношения к разработке проекта. И занимаются ими менеджеры по другим вопросам.
Total votes 2: ↑2 and ↓0+2
Кирилл, я могу согласиться с тем, что бизнес-аналитик может снять задачу и преобразовать ее в требования, но это предельный фэн-шуй мечты ;)) я работал на проектах с крупными интеграторами уровня Люксофта и там тимлид ездил собирать задачу. Проекты шли вполне успешно.
Total votes 1: ↑0 and ↓1-1
Т.е. мой комментарий не в пику вам, а о том, что в большинстве случаев идеально все сделать не получается ;)
This comment wasn’t rated yet0
Бизнес-аналитик это не предельный фен-шуй мечты. Просто он не всегда нужен, например если компания небольшая. То его роль выполнять все же лучше менеджеру проекта, а не тимлиду.
Так то понятно, что из-за недостатка специалистов в большинстве случаев один человек занят в 2-3 направлениях.
Total votes 2: ↑2 and ↓0+2
Исходя из моей практики, менеджеру, как правило, не до аналитики. Просто, деятельность менеджера и аналитика, на мой взгляд, принципиально разная. У менеджера много мелких задач и постоянное жонглирование приоритетами. А у аналитика — основательные длинные задачи, которые опасно делать урывками. Сам много раз видел эпические фэйлы, когда менеджеров заставляли писать ТЗ и при этом у них была пара клиентов с плотными коммуникациями — ничего хорошего не выходило :))
This comment wasn’t rated yet0
А как реализовать постановку задач?

менеджер->тимлид->программисты

Тут через мозг тимлида будет солидный говнопровод

или

менеджер->программисты<-тимлид

Тут тимлид может фокус внимания с задач перевести на кот
Total votes 1: ↑1 and ↓0+1
У меня на практике подход был такой (речь, в основном, про интеграционные проекты, хотя, в интернете почти каждый проект такой):

— Когда начинается новый блок работ (спринт или новый отдельный кусок проекта), мы звали тимлида на встречу с клиентом и его айтишниками (если они есть). Это критически необходимо, потому что менеджер просто не знает, что надо спросить у клиента. Я на своей практике видел менеджеров, которые могли действительно качественно снять задачу с клиента, раза 2-3. Причем, тесно работал и с крупнейшими интеграторами, и со стартапами.

— Если в процессе спринта от клиента прилетают мелкие хотелки, которые довольно просто можно формализовать, они просто добавлялись в бэклог. Если же в хотелке были технические тонкости, то тимлид 100% участвовал в их уточнении. Просто мы выделяли квант времени раз в день на обсуждение новых задач, если это было нужно.

И ничего страшного не произошло — общение тимлида с клиентом было строго пакетировано по времени :)
Total votes 1: ↑1 and ↓0+1
В этой статье мы попробуем разобраться


Но затея не удалась, за попытку — спасибо (с) Юнона и Авось
Total votes 1: ↑0 and ↓1-1
«Наконец, менеджер может быть настоящим продюсером проекта, управляя продуктом сразу с нескольких сторон: дизайн, разработка, маркетинг и т.д. Однако, это очень непростая роль и до нее менеджеру необходимо дорасти и в профессиональном и в личностном смысле.»

Менеджер чего? Проекта? Продукта? Так или иначе, процитированные предложения явно противоречат нормальному жизненному циклу проекта и продукта: вы разберитесь, где и когда заканчивается проект и начинается продукт. Вам правильно сказали: ваша статья выдаёт в вас теоретика.

Ну и как бывший тимлид и ныне менеджер замечу, что многое из написанного вами неправильно. Не только для моего частного случая, но и в общем.
This comment wasn’t rated yet0
Sign up to leave a comment.

Your account

Sections

Information

Services

Support
© 2006–2024, Habr