Як стати тімлідом в IT: 6 якостей ідеального лідера

Мене звати Єгор Горячкін, і я керівник офісів розробки в Forte Group, IT-аутсорсинг компанії.

В IT-індустрії я з 1995-го. За більш ніж 20 років роботи я обіймав різні позиції — від розробника до PMa, від архітектора до делівері-менеджера, а останні 10 років стартую клієнтські сетапи від однієї до десятків команд, які працюють над одним продуктом. Я починав як розробник програмного забезпечення і пройшов такий кар’єрний шлях: тімлід — архітектор — проєктний менеджер — делівері-менеджер. Відкривав представництва IT-компаній в Білорусі, Польщі, Іспанії. Зараз живу в Україні й очолюю delivery-центр Forte Group в Білорусі, Україні та з недавнього часу в Колумбії.

Хто такий тімлід? Як ним стати або зрозуміти, що це не ваше? Чи потрібна лідеру ІТ команди спеціальна освіта? І чому на тімліда завжди буде попит? Відповіді на ці запитання ви знайдете нижче.

Ця стаття буде корисною тим, хто відчуває в собі лідерський потенціал, але не знає, як втілити амбіції, та що для цього потрібно.

Ілюстрація Аліни Самолюк

Потреба в лідерах існувала завжди, і можу гарантувати, що ніколи не зникне, навіть у такій високоосвіченій індустрії, як IT. Потреба об’єднання в групи була невіддільною частиною розвитку людської цивілізації. А для того, щоб ці групи не тільки виживали, а й розвивалися і перемагали, лідерство було критично важливим фактором.

Як доказ незамінності лідерства можна навести експеримент Project Oxygen by Google. Компанія Google спробувала позбутися менеджменту в деяких своїх командах, однак через кілька місяців ці команди перестали перформити, і це, по суті, довело зворотне — менеджмент необхідний.

Цей експеримент показав, що навіть в IT-індустрії команди без лідерів не можуть ефективно працювати. Завдяки цим дослідженням в Google сформулювали 10 необхідних рис хорошого менеджера, які згодом допомогли поліпшити показники плинності та задоволеності співробітників всередині компанії.

Тімлід у Software-індустрії

Роль тімліда актуальна для всіх видів інженерних команд, а не тільки програмістів, зокрема для DevOps, тестувальників та всіх інших, що працюють в галузі Software.

Я вважаю, що для того, щоб бути успішним менеджером і якісно виконувати свою роль, тімліду необхідно:

  • бути основним сполучником між командою і зовнішнім середовищем (наприклад, керівництво, клієнт та інші стейкхолдери). Тімлід — це голос команди зовні, своєрідний буфер між зовнішнім середовищем і командою, який розподіляє завдання, стежить за навантаженням, через якого зручно спілкуватися і якому можна довіряти. Тімлід представляє єдину думку команди і забезпечує комфортне середовище для злагодженої роботи всіх її членів;
  • виконувати функцію people management. Тімліди курують, спрямовують і надихають, слугуючи не тільки технічними експертами, а й рольовою моделлю для інших членів команди. Наприклад, у проєктах Forte Group тімліди самостійно опитують людей і наймають команду «під себе», щоб збігатися на культурному і ціннісному рівні;
  • володіти інструментами та методологіями, за якими працює команда. Наприклад, якщо команда використовує Scrum у процесах, тімлід повинен в цьому добре розбиратися;
  • розуміти весь цикл розробки. Не потрібно бути експертом у всіх сферах, але тімлід має знати всі компоненти Software Development Life Cycle (SDLC), починаючи з моменту появи завдань у беклозі та завершуючи релізом артефакту на продакшн. Необхідно мати розуміння як повної картини, так і її складових: дизайн, розробка, контроль якості, інфраструктура, реліз, бізнес-аналітика тощо;
  • брати на себе відповідальність за те, що команда як юніт працює в тому форматі, який від неї очікують, робить це передбачувано, ефективно, якісно, в рамках процесів, інструментів і правил, ухвалених в організації.

Моїм найкращим тімлідом був на початку 2000-х Андрій Ф. в Мінську. Він сам, без будь-якого прохання з мого боку (а в ті роки я ще був досить сором’язливим), пішов до свого менеджера і дав позитивний фідбек про мою роботу. Андрій заявив, що я не вимагаю менеджменту з його боку ні щодо роботи, ні щодо комунікації з клієнтами, і взагалі можу бути керівником для інших. Цим він дуже допоміг мені, по-перше, підвищити впевненість у собі, у своїх силах, а я тоді потребував зовнішньої оцінки, і, по-друге, перейти на позицію тімліда.

Профіль тімліда

У процесі своєї роботи я довго спостерігав за людьми, за їхнім розвитком і становленням як тімліда. Це допомогло мені сформувати 6 рис ідеального Team Lead в IT-індустрії:

1. Passion, або поєднання щирого інтересу до своєї роботи та готовності пожертвувати чимось особистим на користь оточення. Якщо жертви у вигляді власного часу або комфорту викликають у вас почуття несправедливості й ви до них не готові, тоді роль тімліда не зробить вас щасливими.

2. Комунікативність.Тімлід повинен бути професійним комунікатором. Хороша новина: це не означає, що обов’язково потрібно бути екстравертом. Тімлід має вміти структурно викладати свої думки, швидко відповідати, відчувати контекст.

Тут дам невелику пораду щодо грамотного фідбеку. Я вважаю, що ідеальних людей не буває, тому важливо вибудовувати відносини так, щоб максимально «вмикати» позитивні риси людини та нівелювати негативні. При потребі підкоригувати чиюсь роботу та дати зворотний зв’язок, який можуть сприйняти як негативний, варто приготувати заздалегідь щось хороше для відгуку та завжди завершувати розмову на позитивній ноті. Це маленька маніпуляція, але вона добре працює в житті :)

3. Ментальна «maturity» (зрілість) і стабільність у стресових ситуаціях. Відповідальність і стресові ситуації йдуть пліч-о-пліч, а тому неминучі. Якщо вам складно впоратися із сильним стресом, він негативно впливає на ваше здоров’я, наприклад, з’явився тремор в руках або залежність від кави, варто тверезо оцінити свої навички стресостійкості та зрозуміти, чи можете ви їх прокачати без шкоди для здоров’я, або піти на більш спокійну роль.

4. Вміння давати зворотний зв’язок і навчати оточення. Лідер, який не працює у дві сторони, не вміє доносити ідеї та не дає зворотний зв’язок, не зможе побудувати ефективну команду.

5. Не боятися конкуренції. Якщо фахівець переходить на лідерську позицію, він повинен бути готовий до атмосфери суперництва. На ролі мідл- і топменеджменту часто заходять люди з генами «альфа», тому змагальний момент у цьому середовищі є природним фактором.

6. Професіоналізм в технічній сфері. Тренди змінюються, однак впевнене володіння хард-скілами (чи це Front-end, Back-end або DevOps) — необхідна умова. Без високого рівня знань вам важко буде завоювати авторитет в команді крутих фахівців.

Найважливіше та найскладніше, на мій погляд, що повинен робити будь-який лідер — це розвивати свою команду. Вона складається з індивідуальностей, кожен зі своїм життєвим досвідом, особливостями сприйняття і здібностями до розвитку.

«М’яз», який мені вдалося накачати — це здатність працювати з широким діапазоном людей із різних культур, релігій, країн, які поділяють різні системи цінностей. Мені приємно спостерігати, коли мої співробітники розвиваються. І навіть якщо їм стає тісно в моїй команді і вони йдуть туди, де є більше простору для самореалізації, мені приємно бачити їхній успіх.

Ким тімлід не є

  • Не РМ. Тімлід не зобов’язаний планувати обсяги робіт або відповідати за бюджети, однак може брати на себе частини функції проєктного менеджера. РМ — це окрема роль, адже проєкт завжди має початок і закінчення, а тімлід залишається з командою постійно.
  • Не Scrum-майстер. Розбиратися в Scrum-методології, тому що це стандарт в IT-індустрії на сьогодні, обов’язково, однак якщо пірнати в усі нюанси Agile, фокус тімліда розмиється.
  • Не toastmaster. Тімлід — не тамада, який розважає свою команду. Якщо ви веселий хлопець-координатор, у якого вийшло об’єднати навколо себе людей — це радше компроміс, ніж професійне лідерство.
  • Не старший розробник у команді, який пише найскладніший або найоб’ємніший код. Тімлід — це повнометражна професія, де на перший план виходять комунікації та people-менеджмент. Тому фахівцям, які планують стати тімлідами, розробкою доведеться пожертвувати.
  • Не архітектор. Знання побудови архітектури важливе, але воно не є критично необхідним. Архітектуру можна зробити колективно, і часто буває, що архітектор — окрема роль в команді або на кілька команд.

Одного разу я знехтував власним правилом і поплатився за це. Був один випадок в молодості, коли моїй команді доручили зробити редизайн сайту компанії. А я, скориставшись високим ступенем автономності в ухваленні рішень, взяв на себе роль продакт-оунера, не уточнивши заздалегідь реальні цілі редизайну та очікування бізнесу. У підсумку наш прототип був беззаперечно відхилений, тобто півтора місяця (!) роботи команди пішло в сміття. Урок я засвоїв!

Як стати тімлідом

Тімліди, яких я зустрічав під час своєї практики, можна розділити на дві категорії:

  • Ті, що зробили себе самі, завдяки особистісному зростанню та інвестиціям в освіту.
  • Ті, хто народився з лідерським потенціалом і мають сильну внутрішню мотивацію, бажання керувати іншими, вести за собою.

На зорі індустрії лідерами команд ставали люди із вродженим потенціалом, тому що не існувало підходів, вимог до освіти, не були налагоджені процеси. Зараз IT-сфера істотно ускладнилася. Щоб бути хорошим лідером, потрібна освіта, треба навчитися працювати менеджером в Agile-середовищі, бути готовим до постійного розвитку.

Люди, які просунулися на менеджерські позиції, але не пройшли навчання, не дотягують до своїх колег з освітою. У них є «вогонь» і проактивність, однак рівень культури залишає бажати кращого, професіоналізм часто на рівні «3 з 5». В інженерній індустрії професіонал з необхідною освітою має авторитет апріорі, завдяки чому значно зростає ефективність команди з таким лідером.

Запам’ятайте: ні вік, ні стать у кар’єрі тімліда не мають такого значення, як розвинені особистісні якості та знання, які перераховані вище.

І останнє: якщо ви хочете стати успішним тімлідом, почніть думати про IT-індустрію як про бізнес. Про це часто забувають. Зрештою, ми працюємо в компанії, основною метою якої є успіх на ринку і прибуток. Коли ви розробник або тестувальник, то ви ізольовані від бізнес-середовища, але, потрапляючи в менеджмент, опиняєтесь в групі людей, на яких компанія спирається при ухваленні важливих рішень щодо просування бізнесу.


Сподіваюся, мої думки та досвід, якими я поділився в цій статті, допоможуть вам сформувати правильний образ тімліда і вирішити для себе, чи готові ви до такого виклику. Успіхів!

👍НравитсяПонравилось18
В избранноеВ избранном5
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Скажіть, а які книги з керування в ІТ ви порадите з того, що прочитали останнім часом?

Сергей, добрый день, у сожалению не могу что-либо из книг рекомендовать( не потому, что книг не существует, возможно они есть, просто не известны мне, мы в Forte Group полностью перешли на тренинги, внешние, которые я рекомендовал ниже, и внутренние которые запускаем в компании, в целом от книг как инструмента образования все больше уходим в пользу обучения онлайн (тренинги, видео) т.к. молодежь книги не читает)

6 рис ідеального Team Lead в IT-індустрії:
1. Passion
«щоб очі горіли»? Це ж тупо. Професіоналу може не подобатися його поточний проект, в нього може загалом бути етап в житті, коли він на роботу ходить гроші отримувати, а конкретно зара йог цікавить підготовка подорожі для політу на параглайді, але він професіонал і буде якісно виконувати свої обов’язки по проекту.
«Якщо жертви у вигляді власного часу або комфорту викликають у вас почуття несправедливості й ви до них не готові» — то такого готові лише терпіли, які не цінують власне життя. Овертайми оплачуються завжди, або компенсуються тим, що в наступні дні я менше працюю. Якщо овертайми виникають кожного дня контора — лайно.
2. Комунікативність.
Тут ок.
3. Ментальна зрілість і стабільність у стресових ситуаціях
Також ок, але всі 21-річні тімліди зараз поперхнулися молоком )
4. Вміння давати зворотний зв’язок і навчати оточення.
В ідеальному світі кожен тімлід мав би мати такі якості..
5. Не боятися конкуренції.
Гени «альфа» — це типу як зайва хромосома у росіян? )))
6. Професіоналізм
Прикольно, що професіоналізм стоїть на останньому місці )

6. Професіоналізм
Прикольно, що професіоналізм стоїть на останньому місці )

Тарас, спасибо что обратили внимание, это была ошибка в тексте, я исправил, здесь имеется ввиду профессионализм в технической сфере, то что в комментариях ниже обсуждалось, на сколько важно быть и тех- и тим- лидом одновременно, я считаю это достаточно важно для успеха но место в списке приоритетов — ближе к концу списка :)

Насправді тімлід невеликої команди це досить часто дійсно просто отой contact point із софт-скіллами, якого інші обирають чи призначають репрезентувати команду і не раз не більше того. В нас у полісі сказано, що це посада, на яку можна брати, починаючи з кваліфікаційного рівня мідла, хоча по замовчуванню людина з рівнем сіньйора має пріоритет перед мідлами, а вже з рівнем Lead ця посада дістається по замовчуванню.
На практиці це не раз не означає навіть сеньйорності, не кажучи вже про готовність вести за собою. Чи буде така людина саме техлідом, технічним керівником — тут гарантії немає.
Отут і є дихотомія — тімлід частіше балакає за всіх, тоді як техлід приймає і узгоджує технічні рішення і якраз-таки сприяє зростанню колег. Техлід найчастіше є й тімлідом, а от тімлід техлідом є не завжди — рішення можуть прийматися поза командою або в команді, або не ним.
Ну і тут вже доводиться вибирати, бо до техліда ще треба дорости, як технічно, так і особистісно, а гібридом інженера і координатора може бути будь-хто з софт-скілами і організаційними здібностями дещо вище плінтуса.
На своїй першій лідській позиції я десь таким і був дев‘ять років тому, в мене й тайтл був відповідний — «Team Leader». Тішився, з організацією щось виходило, власний код теж писав більш-менш, але технічно на той момент мені, десктопо-сільверлайтнику, ефективно лідати веб-девелоперів не дуже вдавалося, бо я лише в‘їжджав у той же MVC. На виході наш сіньйор клепав у 2012-2013 рр. aspx, робив model first у Enitty Framework та спирався на сторьки (SP) для маніпуляцій і навіть отримання даних, що вже тоді було відвертою дичиною, проте ні в мене, ні в мідла не було достатньої експертизи, щоб дати цьому оцінку, а він сам так звик, йому було норм...

Сергей, дихотомия, разделение между тех-/тимлид команды во многом искусственное, нельзя это разделять (имхо). Это происходит потому что из-за нехватки эффективных лидеров, целостных и в софт и в хард скиллах, компании, решая проблему управления и коммуникации с командами разработчиков, ставили «сверху» не технических координаторов и чтобы компенсировать дисбаланс выделяли технических лидеров отдельно. Я наблюдал это и могу сказать что технические команды с не-техническими лидами либо не могут создать комфортную и продуктивную рабочую атмосферу, либо команды дистанцируются от своих «лидеров» и живут своей жизнью а их «лидер» своей.

разделение между тех-/тимлид команды во многом искусственное, нельзя это разделять (имхо).

можно и нужно

Это происходит потому что из-за нехватки эффективных лидеров

как раз это всё на оборот и это объединение ролей происходит из-за не хватки реальных людей способных реально решать вообще и решать вопросы в частности

ЗЫ: вообще это не специфика программирования это везде так

либо команды дистанцируются от своих «лидеров» и живут своей жизнью а их «лидер» своей.

я давно придумал этот принцип двойной бухгалтерии и везде его практикую )) работает достаточно просто достаточно понятно рядовым и работает вообще просто потому как

youtu.be/1CLBANCVHTw?t=96

селяви а как ты правильно заметил жить с этим как-то надо ))

Статья походу про тимлидов в реалиях украинского аутсорса — и танцевать, и петь, и на дуде дудеть. И скрам мастер, и тех лид, и продакт оунер, и девелопер, и персов своих качай. Как в рекламе Билайна — «все вместе и ни*я толком». Ну нереально одному человеку эффективно и качественно совмещать все эти роли на проектах промышленного масштаба.

Архітектуру можна зробити колективно

на этом месте мне стало страшно...

Вона і робиться колективно :) Якщо подивитися уважніше та розібрати в деталях, виявиться, що одна людина рідко коли зможе розробити архітектуру від «а» до «я». Бо в сучасних реаліях вона включає ті області, в яких треба користуватися консультаціями спеціалістів саме з тієї області — DevOps, QA, Security, або System Administration. Жоден архітект не закриє всі області. Мова про LLD, зрозуміло.

на доу каждый, считающий себя крутым синьер-тимлид-аркитектуром обязан высказаться о своём успешном успехе? Воняет же! Даже когда мимо темы проходишь.

Ніт, давайте слухати таких як ти.

Тимлид это какой-то очередной мифический «фулстек» получается:
— Не ПМ, но фактически выполняет его работу.
— Должен быть девелопером, но при этом не самый опытный синьор.
— Не архитектор, но должен разбираться в архитектуре.
Звучит так, что это обычный девелопер, которому ПМ, техлид и архитект делегируют свою работу. А он за лычку тимлида все это тянет, еще и код пишет. При этом никаких реальных рычагов на что-то влиять у него нет.
Что бы разобраться кто такой тимлид в вашем понимании — напишите сколько рабочего времени он должен уделять коду, архитектуре, и сколько переписке, общению с клиентом и командой, отчетам. Ответ «он должен это все успевать потому что быть тимлидом — большая честь» не принимается!

делегируют свою работу

теперь это называется «делегируют» ))

автор же написал — тимлид не должен кодить. он как бы ментально посылает свои бест практиц из головы на остальную тиму, в соответствии с аджайлом и кзот

Звучит так, что это обычный девелопер, которому ПМ, техлид и архитект делегируют свою работу.

Так и есть :)

Добрый день, по поводу

напишите сколько рабочего времени он должен уделять коду, архитектуре...

если взять за пример среднестатистическую команду 5-7 человек, работающую по скраму, с хорошим продакт оунером и более-менее качественным бэклогом, на практике у тим лида остается 20-30% времени чтобы кодить в свое удовольствие :) если среда вокруг команды такая что перегружают репортами и митингами, в такой среде у тим лида может быть 0% кодинга, просто ни времени ни желания не остается

сорян чувак но если там скрум как скрум со всем красивым то там роли лида просто нет все просто сидят и кодят и ни каких

на практике у тим лида остается 20-30% времени чтобы кодить в свое удовольствие :)

тут либо шашечки либо крестик

а тимлид становится скраммастером. оп! многоходовочка

Роль скрам мастера лелеять скрам. Ему в идеале все эти ваши дэдлайны, предметные области и прочая прикладнуха до балды. «У самурая нет цели, есть только путь».

А кто-то все таки должен репортить менеджменту, участвовать в проджект митингах от лица команды, проводить "one 2 one«ы, пушить всякую корпоративную дичь на уровне команды, хэндлить взаимнЫй фидбэк от команды к менеджменту, знать ответ на извечный вопрос «are we on track?» и пр и пр и пр.

Скрам мастер этого всего делать не обязан. Эти допы можно ему конечно и подкинуть в гнездо. Но тогда может случиться конфликт интересов — либо скрам по понятиям, либо «стулья вперед».

Тогда я не понимаю смысла: технических специалистов сейчас на рынке дефицит. При этом не-технических «управленцев» найти вообще не проблема.
Вы берете девелопера — и делаете из него тим-лида, который или вообще не кодит или всего 30% времени. Не проще ли нанять не-технического ПМа (студентку с иньяза) — которая будет 100% времени заниматься отчетами, митингами, мотивацией команды, коммуникацией с клиентами и т.д. А девелоперы будут спокойно писать код и не отвлекаться?

Вы берете девелопера — и делаете из него тим-лида, который или вообще не кодит или всего 30% времени. Не проще ли нанять не-технического ПМа

Подмечено верно, технически мы как бы теряем одного пишущего код разработчика, но задача тим лида вкладывать в развитие участников команды, дать максимально раскрыть потенциалу каждому, и таким образом за счет раскрытия других компенсируется «потеря». Более того, в команде где тим лид вкладывает себя в развитие других, формируется гораздо более комфортная рабочая атмосфера, в такой команде интереснее работать, появляется дополнительный смысл. НЕ технический ПМ/СМ/Студентка и т.п. не сможет этого добиться потому что сколько книг по аджайл не прочитай, даже если манифест наизусть выучить :) если сам не кодил, не прошел этот этап, никогда в глубине души не поймешь проблем другого разработчика.

бред )) просто у вас у дикарей нет ни какой бизнес культуры в т.ч. и отдельно культуры пипл менеджмента

youtu.be/O3l5_MjR0Dw

youtu.be/VYjcYkcLYZM

тут на доу была как раз просто отличная статья которая я лично даже кратко и 146% точно изложил как

Эйчар здесь бесполезен.

вот всё что там на писано ты тут снова повторяешь ровно в слово опять

но задача тим лида вкладывать в развитие участников команды, дать максимально раскрыть потенциалу каждому, и таким образом за счет раскрытия других компенсируется «потеря».

Пафос на максимум прям выкрутили.

Что значит компенсируется потеря? Типа «отряд не заметил потерю бойца»? А слабо просто начальству сказать: «у нас минус один. Предполагаемая велосити команды будет на N% меньше. Смиритесь.». Я понимаю, что в аутсорсе погонщики ценят «безумие и отвагу», но блин...

а где картинка «начальник vs лидер»?

Очень у вас расплывчатое описание. Описываете вы классического линейного менеджера с набором именно менеджерских навыков управления людьми и процессами. Отдельно останавливаетесь на гибких методологиях, координации и т.д. Потом пишите что тим-лид — это не менеджер и не может вмешиваться в обьем работ, сроки бюджеты и т.д. но при этом должен за выполнение всего этого отвечать т.к. представляет не себя — а команду. При этом пишите что тим лидер так же и не ведущий тех специалист, ба для этого есть другие люди. Тогда кто ? Извините вижу полную не стыковку. Ну или вы описываете «погонщика» задача которого орать на молодых чтобы те ишачили в три смены, желательно бесплатно — а ещё лучше чтобы ещё и приплачивали.

Щоб бути хорошим лідером, потрібна освіта
Люди, які просунулися на менеджерські позиції, але не пройшли навчання, не дотягують до своїх колег з освітою.

Що б ви порадували в якості освіти для цієї ролі? (Які книжки / курси?)

Илья, если говорить в общем и целом, я рекомендую пройти курсы Agile Fundamentals Scrum/Kanban (ICP) и затем Agile Project and Delivery Management — это уровень выше, но я считаю это полезно для тим лидов и тех, кто хочет стать тим лидом. Это условно говоря «хард» скиллс. Софт скиллы, я честно не знаю таких программ, компании где я раньше работал и где сейчас работаю тренинговые программы для лидеров готовят внутри компании, на них нельзя попасть извне. Также я лично трачу много времени работая с тим лидами в Forte Group, это и менеджмент и персональный коачинг, два в одном, эта работа всегда сугубо индивидуальна с каждым конкретным человеком, с учетом индивидуальности.

Так стоп. Вы рекомендуете человеку претендующему в будущем на позицию тим лида курсы по Скраму/Канбану/Аджайл? Почему именно эти фреймворки и методологии?

RUP (к) (тм)

Тогда уж и ROP. Почему бы и нет.

Лідерами стають не після читання книжок. А після тривалої практики в цьому. Бо це не академічна наука, а модель поведінки :) ТС трохи заплутався в цьому, схоже, тому рекомендує почитати про Agile :)

Щось забагато треба вміти і робити за таку незначну надбавку до ЗП, вам не здається? :) Краще бути звичайним інженером в обоймі, жити спокійно і не брати зайвої відповідальності на свою шию. А вільний час витрачати на самовдосконалення та на свій другий проект, за який буде значно грошей, ніж за позицію тімліда :) Як тобі таке, Ілон Маск?

Невелика така надбавка. Вам не пропонували? Треба вимагати, добиватися свого :)

Не згодна що тімлід це people manager. Це частіше різні позиції які вимагають різних навичок

Це старе питання про дихотомію тімлід-техлід.

Наприклад, якщо команда використовує Scrum у процесах, тімлід повинен в цьому добре розбиратися;
бути основним сполучником між командою і зовнішнім середовищем (наприклад, керівництво, клієнт та інші стейкхолдери).

приехали

Подписаться на комментарии