Home

Авторский коллектив: Артём Торосян (HR manager VDI), Евгений Грачёв (Project Manager VDI)

Цель этого документа — дать добрые советы любому начинающему руководителю группы.Руководитель группы это не человек, который заполняет планы. Руководитель группы — это лидер коллектива, который может привести коллектив к вершине, а может увлечь в пропасть.В документе собраны советы, которые покрывают наиболее ключевые области работы руководителя. Это советы не теоретиков, это советы практиков.Прочитайте этот документ, проникнетесь им и попробуйте следовать этим советам. Это не просто, но это стоит делать.

 Содержание

• Работа с людьми
• Ответственности
• Оценки трудоемкости
• Переработки
• Планы и отчетность
• Добрые советы, по организации рабочего процесса
• Резюме

Работа с людьми

Вам подчиняются люди. Качество их работы во многом зависит от качества Вашей работы. Иными словами Вы непосредственно влияете на благополучие сотрудников в компании.

Вы отвечаете за работу каждого вашего подчиненного. Если человек дает плохое качество и Вы об этом узнаете от кого-то — это Ваша вина.

Например. Разработчик отчитывается о сделанном функционале, и Руководитель группы разработки (ЛидДев) заявляет функционал в тестирование. Если после этого тестировщик говорит, что все не по дизайну или половина дизайна не сделана — виноват ЛидДев.

Вы можете аргументировано затребовать снятия человека с проекта (направления) — примеры тому были — но если Вы продолжаете работать с человеком и не ставите Руководителя проектов (PM) в известность о проблемах, то это Ваши проблемы. Для PM это значит, что Вы готовы помочь человеку и это:

• Не отразится на качестве выходных результатов по задачам этого человека
• Не отразится на сроках выполнения, как ваших задач, так и задач человека, которому Вы помогаете
• Не отразится на качестве Вашей работы на ваших задачах

Иными словами, если Вы покрываете человека, и PM не в курсе, то аргументы типа «я тут и так зашиваюсь, а меня еще спрашивают по моим задачам» или «давайте я все брошу и буду делать то, что обещал(ла)» не проходят.

Если Вы видите у человека проблемы, которые не можете решить в рабочем порядке, Вы обязаны обговорить это проблемы с человеком, чтобы сотрудник понимал, что Вы им не довольны. Вы должны не просто указать на проблему, но и аргументировать, что это действительно неправильно и дать рекомендации к исправлению. Если договориться с человеком не получается — говорите PM, и решайте совместно.

Каждую минуту рабочего дня Вы обязаны знать, чем занят каждый Ваш подчиненный и когда он закончит поставленные задачи. Для этого не обязательно его дергать ежеминутно, достаточно понимать, когда он закончит и на протяжении срока выполнения уточнять укладывается ли сотрудник в сроки, и нет ли проблем. Иногда проще созвониться, иногда подойти... как оптимальнее — пробуйте, подбирайте...

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

Вы не должны все делать своими руками, это значит, что Вы можете распределять часть своих обязанностей между подчиненными. Это позволит:

• Не умереть от загруженности
• Вовлечь в процесс других сотрудников и обучать их
• Сплотить команду

При проставлении еженедельных оценок сотрудникам Вы обязаны быть готовы объяснить сотруднику и PM, почему именно эту оценку Вы поставили.

Многие вопросы легче решать по телефону. Не ленитесь звонить в удаленные офисы... не надо создавать у удаленных сотрудников ощущение, что они на отшибе... это Вам же будет мешать, когда они замкнутся и информацию придется вытягивать.

Помните, про то, что все люди разные — Вы как руководитель обязаны научиться работать с человеком. Понять, КАК ему лучше ставить задачи, КАК его оптимальнее мотивировать на работу, КАК ему говорить об ошибках. Поймите, Вы можете сильно травмировать человека неосторожным словом... Вы можете часами объяснять человеку что-то и он никогда Вас не поймет, если Вы будете говорить непонятным для него языком и приводить несущественные для него доводы. Если Вы не найдете общий язык с человеком, Вы не сможете с ним оптимально работать. Причем подстраиваться зачастую должен не только он, но и Вы. Помните, про национальные различия. Хороший руководитель обязан знать основные национальные черты и особенности подчиненного.

Помимо работы с подчиненными Вы обязаны тесно работать со своим коллегой (2-м лидом). Для лидQA неприемлемо не знать дат ближайших билдов... для ЛидDEV неприемлемо не знать дат окончания основных этапов тестирования. ЛидDEV обязан делать ревью тестплана, ЛидQA — ревью дизайнов. За качество конечного продукта отвечают оба лида. Перед тем как говорить, что сроки двигаются из-за того, что тестировщики слишком поздно находить начали баги, подумайте, может девелопмент давал настолько сырые билды, что QA затратили на тестинг и багретест больше времени, чем планировалось? Перед тем как говорить, что сроки двигаются из-за того, разработчики все в последний момент правят, подумайте, может это QA тестирует дольше, чем планировалось?

Ответственности

Под чем Вы подписываетесь, и что это значит:

• Заявка в тестирование — форма, которой ЛидДев подписывается под выполненной разработчиками работой
• Отчет по заявке — форма, которой ЛидQA подписывается под качеством проверенного билда
• Пройденный Тест план — подпись ЛидQA под качеством проверенных частей системы
• Дата окончания тех или иных работ — подпись лида под обязательством сделать что-то в оглашенное время

Любая неправильно поставленная подпись свидетельствует о том, что Вы плохо сделали работу. Бывали случаи, когда людей увольняли за подобные ошибки (к вопросу о серьезности).

За проект отвечает PM, если Вы принимаете решения вне зоны Вашей компетентности без ведома PM, значит Вы берете всю ответственность по этому вопросу на себя.

ЛидQA отвечает за оптимальный процесс тестирования на проекте. Оптимальным считается самый быстрый процесс, обеспечивающий своевременное нахождение багов и требуемое качество в результате.

ЛидДев отвечает за оптимальный процесс проектирования и разработки на проекте. Оптимальным считается самый быстрый процесс, обеспечивающий своевременные выдачи билдов в тестирование с заранее оговоренным качеством 

Лиды обязаны своевременно отвечать на письма заказчика. Ни одно письмо не должно остаться без ответа. Если ответ не готов, то обязательно надо отписать, что ответ не готов, будет готов тогда-то. Если письмо касается Вашего проекта, но Вы не собираетесь на него отвечать, то обязательно скажите об этом PM. Если у Вас нет времени прочитать/ответить на письмо, обязательно пишите об этом PM.

Не ленитесь давать заказчику как можно больше информации. Помните, Вы потратите больше времени на понимание уточняющих вопросов и на подготовку ответов на них, если напишите что-то абстрактное или плохо структурированное. Помните, Ваше письмо будут читать люди разного ранга и с разным пониманием проблемы. Ваше письмо должно быть понятно им всем. В идеале оно должно быть интересным.

Если Вы пишете о проблеме или готовите вопрос, письмо всегда должно содержать:

• Вводную информацию — поймите, это Вы занимаетесь проблемой, и заказчик вообще не в курсе того, о чем Вы пишите и почему Вы это делаете
• Описание проблемы/вопроса
• Варианты решения с указанием плюсов и минусов и влияния на проект
• Рекомендации

Оценки трудоемкости

Вы отвечаете за оценки трудоемкости, которые даете. Не зависимо от того, кто оценивал — Вы или Ваш подчиненный. Не всегда возможно дать четкую оценку, но в этом случае, PM должен видеть оговорку, что оценка неточная и причину, по которой более точную оценку дать было нельзя. Если Вы даете  оценку, без каких либо оговорок, РМ считает ее окончательной и дальнейшие отговорки типа «ну я же быстрее оценить хотел (ла) и не успел (ла) все проверить» или «всегда есть риск» не проходят.

Вы не должны подгонять оценки под желания заказчика или PM. Если задача делается за 5 дней, а через 4 дня доставка — это не Ваша проблема. На основании информации от Вас PM принимает решение, как поступить. PM может принять решение делать за 4 дня но только если он:

• Договорился с Вами о переработке или
• Согласовал с Вами, как можно урезать задачу или
• Предлагает Вам помощь

В любом случае урезания сроков без Вашего ведома и согласия не было и не будет. PM просто не имеет права это делать.

Всякий раз, когда Вы оцениваете ту или иную задачу, Вы оцениваете наилучшее ее исполнение. Если Вы идете на компромиссы и это может отразится на качестве, Вы обязаны согласовать это с PM. Отговорки типа «я хотел (ла) сделать как можно быстрее, время было мало, поэтому получилось плохо» не проходят, если PM не был предупрежден. 

Оценки всегда должны даваться из расчета 8-ми часового рабочего дня.

Вы обязаны уметь аргументировано защищать каждую данную Вами или Вашим подчиненным оценку. Если защитить не готовы — должна стоять соответствующая пометка, чтобы PM знал об этом. Зачастую, если PM спрашивает почему эта задача занимает 5 дней, а не 3 — это не «наезд» и не недоверие — это желание разобраться и убедиться в том, что Лид все продумал. Если в ответ на это следует ответ — «ну можно и за 3» или «ну мне кажется, что за 4 не успеем, а за 5 скорее всего успеем», то это большой красный флаг, что Лид дал оценку с потолка.

При работе над оценками Вы должны углубиться в вопрос настолько, насколько это требуется для выдачи наиболее точной оценки. Иногда PM может потребовать оценки АСАП, в этом случае лид должен оговориться, что оценки не точные, если не успел досконально вникнуть в вопрос и по возможности дать вероятный разброс.

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

У каждого лида есть таск leadership. По опыту других проектов — это 10% от всего девелопмента. Но эта оценка может и должна меняться, если того требует специфика проекта или команды.

В leadership входит:

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

Переработки

Переработки возможны в следующих случаях:

• PM попросил переработать — будет компенсировано либо отгулом, либо доп. оплатой (переработка в выходной обычно х2, в рабочий день х1.5)

• Подвела команда (например, тестировщики затянули хождение TP, поздно нашли баги и в результате, разработчикам приходится фиксить баги в очень высоком темпе, что часто приводит к переработкам. ИЛИ. Разработчики дали билд позже, чем планировалось и его надо тестить АСАП, что тоже часто приводит к переработкам). В подобных случаях вопрос о компенсации рассматривается отдельно. Вы должны помнить, что работаете в команде, и любые ваши ошибки отражаются на других членах команды и наоборот. Если доставка заказчику не будет сделано по плану, то наказаны будут оба лида, независимо от того, кто сделал ошибку. Поэтому не стесняйтесь требовать со своего коллеги выполнения обязательств в тех фазах, где вы пересекаетесь.
• Сотрудник стремится развиваться и старается сделать больше, лучше — в случае удачи компенсируется повышением ЗП, продвижением по служебной лестнице, желанием PM и других пойти на встречу в случае сложностей.
• Сотрудник отрабатывает отгул

Сотрудник вправе отказаться от переработки, если она не вызвана его ошибками. 

В любом случае, если PM сам не договорился с человеком о переработке, разговоры типа «я и так тут ночами сижу» или «я тут пашу, а вы с меня еще и спрашиваете» или «меня здесь не любят, уйду я на фиг» не проходят, так как человек либо осознанно идет на переработку, либо свои же ошибки правит.

Лид не имеет права договариваться о переработке с сотрудниками без ведома PM — в этом случае переработка может быть не компенсирована.

Планы и отчетность

Планы должны строиться каждую неделю без напоминаний до 19-00 пятницы. Каждый лид планирует своих подчиненных. Если не ясно или есть сомнения, кто кому в данный момент подчиняется (бывает такое, когда человек у двух лидов или только что перешел от одного к другому) Вы обязаны уточнить это у PM.

Еженедельные статусы  должны отражать все, что происходило на проекте за неделю + освещать открытые риски и вопросы.

Cотрудники проектной команды обязаны присылать ежедневные отчеты и делать это в конце рабочего дня (а не утром следующего). Лид отвечает за то, чтобы отчеты приходили от всех его подчиненных ежедневно. Если отчеты не приходят в течении 2-3-х дней, для PM это значит, что лид плохо делает свою работу.

План всегда должен отражать реальное положение дел. Не фантазируйте, сами же потом запутаетесь. Не допускается иметь в плане закомпличенными задачи типа bugfixing, bugretest, customer support и т.д.

Работайте с планом постоянно — Вы сами увидите, как это облегчит Вам работу — у Вас всегда будет полная картина перед глазами.

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

Если Вы чувствуете, что человек не до конца понял задачу или Вы сомневаетесь, что он все запомнил, что Вы объясняли, требуйте прислать письменный отчет о понимании задачи. Помните, качество постановки задачи влияет на качество и сроки исполнения.

Принимайте это во внимание при планировании и оценках. Не забывайте, что не все присутствуют на митингах по обсуждению той или иной проблемы, не все участвуют в переписке с заказчиком. Многое, очевидное для Вас, совсем не очевидно для Ваших подчиненных.

Добрые советы, по организации рабочего процесса

1. Всегда ведите список своих задач на ближайшее время. Удобно выписывать их на лист бумаги вначале дня и вычеркивать по мере выполнения. Это позволит правильно расставить приоритеты и наглядно покажет, что еще предстоит сделать.
2. Научите Ваших подчиненных уважать Ваше время, общение с ними не должно занимать Вас на 100%. Если Вы чувствуете, что общение с кем-то занимает очень много времени, проанализируйте, как строится общение, и попытайтесь его оптимизировать. Иначе управляя 10 подчиненными, Вы только и будете успевать, что на вопросы отвечать. НО! Недостатка в общении быть не должно. Общение должно быть оптимальным.
3. Планируйте все, что можно спланировать. Ставьте себе дедлайны по своим таскам и соблюдайте их.
4. Возьмите за правило регистрировать ключевые моменты, произошедшие за неделю, как в ходе проекта, так и в управлении командой — это поможет Вам при составлении недельного отчета и оценке ребят за неделю.
5. Вот ключевые моменты дня:
   • Начало дня
   • Ревью почты и определение писем, требующих вашего ответа
   • Ревью списка оставшихся задач, составление задач на день
   • Оценка задач и определение приоритетов и последовательности выполнения (оставляйте время на непредвиденные задачи, сколько? смотрите по опыту на проекте).
   • Работа по задачам, апдейт списка задач
   • Прочтение дейли репортов от подчиненных, коррекция их действий, если надо
   • Ревью списка задач
   • Конец дня
6. Не доводите до того, что у Вашего подчиненного осталось задач меньше, чем на день. Если человек во что-то уперся, и у Вас нет возможности ему быстро ответить, у него должен быть список работ, на которые переключиться, иначе Вам придется всем отвечать АСАП.
7. Ставьте себе дедлайн по уходу работы и стремитесь в него вписаться, выполнив все запланированное... частые переработки и работа ночами быстро истощает.
8. Не давайте команде вести Вас, Вы должны вести команду.
9. Старайтесь всегда иметь запас до дедлайна, никогда не планируйте и не работайте впритык. Всегда добавляйте время на непредвиденные ситуации.
10. Старайтесь поддерживать хорошие отношения с подчиненными и коллегами по команде. Бывает, что мы работаем в стрессовой обстановке — в такой ситуации ни в коем случае нельзя ожесточаться и идти напролом. Учитесь слушать и понимать своих коллег. Помните, в VDI в основном работают умные и грамотные люди и если человек поступает определенным образом, значит, у него есть на то причины и их надо понимать и уважать, даже, если человек ошибается.
11. Не стесняйтесь общения с PM — PM и 2 лида — это тройка, которая тащит на себе весь проект, если между ними нет согласованности и единых целей, то это будет лебедь, рак и щука...
12. При планировании бейте задачи как можно мельче — помните хороший план, это больше половины успеха.
13. Не берите на себя то, за что не можете ответить.
14. Избегайте предположений, старайтесь иметь близкую к 100% уверенность в правильности своих решений.
15. Периодически поднимайте голову и смотрите на то, как организован Ваш день, все ли Вас устраивает в процессе работы, не копится ли у Вас негатива, что хорошо, что плохо. Думайте, как улучшить процессы. Не стесняйтесь советоваться с PM. Старайтесь не доводить до того, что PM делает вам замечание. А если делает, то подумайте, почему?

Резюме

• На лиде ответственность за людей, которые ему подчиняются
• На лиде ответственность за то, что делает его команда
• Хороший лид не боится говорить правду
• Хороший лид умеет аргументировано отстаивать свое мнение
• Хороший лид всегда контролирует ситуацию и имеет представление о ходе проекта в целом
• Хороший лид немного психолог, немного воспитатель, немного учитель и всегда надежная опора, как для PM так и для подчиненных и коллег
• Хороший лид умеет организовывать свой день и работу своих подчиненных, так, чтобы успевать делать все запланированное
• Хороший лид всегда развивается, анализируя свои ошибки и успехи
• Без хороших лидов успешный проект невозможен.