Мой первый опыт тимлида: 17 советов самому себе на будущее

Перевод статьи «How I led a team of developers for the first time — 12 tips for the future me».

Photo by Headway on Unsplash

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

1. Все начинается с требований

Нельзя начать что-то строить, если не знаешь, что нужно получить в итоге. Поэтому первым делом нужно пообщаться со стейкхолдерами. Дай им возможность объяснить, что им нужно. Постарайся вникнуть во все детали их требований.

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

2. Планируй техническую часть

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

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

Если в стеке много неизвестных, построй сначала MVP. Это сохранит тебе кучу времени и избавит от головной боли в будущем.

Помни, что планирование и сбор информации снижают вероятность проблем в дальнейшем.

3. Твои планы не высечены в камне

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

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

4. Убедись, что все понимают план

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

Это важно по многим причинам. Благодаря этому:

  • члены команды понимают, зачем нужна каждая задача;
  • они получают возможность выдвигать идеи об улучшениях;
  • когда тебя нет рядом, люди знают, куда двигаться дальше;
  • самое главное — в ходе работ все видят прогресс и оставшуюся часть работы.
Photo by You X Ventures on Unsplash

5. Минимизируй зависимость от других людей (отделов)

Чтобы сэкономить время и обеспечить плавное течение работ, старайся минимизировать все зависимости от других людей. Или, по крайней мере, начинай работать над ними в самом начале проекта.

Например, если тебе для проекта нужен дизайн, пускай дизайнеры подготовят его до того, как начнутся работы над проектом. Обязательно убедись, что тебе как разработчику и тимлиду там все понятно.

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

6. Приложи дополнительные усилия, чтобы разделить задачи на части

Что касается создания задач… Дели их на маленькие кусочки и, в идеале, сопровождай рекомендациями по решению. Благодаря этому членам команды будет проще создавать и тестировать решения каждого такого кусочка, а также делать ревью кода. Помимо всего прочего, такой подход обеспечит людям постоянное ощущение достижений.

И да: нет нужды создавать все «таски» самостоятельно. Проводи еженедельные собрания, на которых вы с командой будете обсуждать и распределять задачи. Это поможет синхронизировать действия членов команды и сразу ответить на все возникающие вопросы.

7. Всегда будь как минимум на шаг впереди

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

С технической точки зрения ты должен знать, как разные части будут соединяться друг с другом. И когда люди будут спрашивать, как их соединить, ты должен суметь объяснить это.

Я советую начинать неделю с утреннего собрания, на котором обсуждать планы на предстоящую неделю и освещать текущее состояние проекта.

8. Следи за тем, чтобы собрания не уклонялись от темы

Общие собрания… Я не фанат митингов, потому что они занимают время всех членов команды. Но вместе с тем обойтись вообще без них тоже нельзя. Поэтому очень важно сделать их как можно более эффективными.

Что я посоветую? Каждое собрание должно иметь повестку дня и список ожидаемых результатов. Поделись всем этим со всеми участниками заранее, чтобы они могли подготовиться. Когда дискуссия уходит в сторону, возвращай людей к основной теме. И следи за часами.

9. Командная культура важна, и ты играешь важную роль в ее создании

Есть одна вещь, о которой я не задумывался раньше. Это важность создания командной культуры. Эту культуру легко считать чем-то само собой разумеющимся, пока работаешь со своими товарищами, которых хорошо знаешь, с которыми уже сработались. Но в моем случае многие члены команды не были знакомы друг с другом раньше. Чтобы это исправить, один из моих коллег постоянно подталкивал нас проводить какие-то командные мероприятия и обедать вместе.

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

Photo by Headway on Unsplash

10. Проводи личные встречи

Я большой поклонник личных встреч. У членов твоей команды есть свои соображения и идеи относительно улучшений в проекте, а личные встречи — отличный способ узнать о них.

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

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

11. Делегируй полномочия и доверяй людям

Один человек не может ни знать всего, ни делать все. Поэтому я советую как можно чаще делегировать полномочия.

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

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

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

12. Будь тем, кто расчищает путь

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

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

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

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

12+1. Не пытайся геройствовать

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

Когда поджимало время и мы сталкивались с большими трудностями, я считал, что объяснять всё и всем это потеря времени, поэтому брался за решение проблем самостоятельно.

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

Вот почему я советую всегда держать команду в курсе происходящего и делить задачи на маленькие кусочки.

13. Сначала слушай других. Свои идеи высказывай в конце

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

Photo by You X Ventures on Unsplash

14. Откажись от подхода «Сделаем это позже». Скорее всего, не сделаете.

Тебе, как разработчику, известно, что к строкам, начинающимся с TODO, обычно так и не возвращаются.

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

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

15. Знай, что нужно тестировать

Мне случалось принимать участие в проектах, где мы делали модульные тесты просто ради 100% покрытия. В конечном итоге нам было очень сложно тестировать, а когда в код вносились изменения, уходило много сил на то, чтобы изменить и тесты тоже.

Но мне случалось участвовать и в проектах, где не было 100% покрытия тестами, однако имеющиеся тесты были эффективными.

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

16. Используй парное программирование как способ распространения знаний

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

17. Меньше обещай, больше делай

Это я усвоил еще когда занимался фрилансом: лучше пообещать меньше, а в итоге сделать больше.

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

Этот подход я применил и к стейкхолдерам последнего проекта. Они спросили, сможем ли мы сделать функции X, Y и Z — я сказал, что нет. Но мы держали эти функции в бэклоге и в конечном итоге одну из трех все же реализовали. Стейкхолдеры этого не ожидали и были приятно удивлены.

[customscript]techrocks_custom_after_post_html[/customscript]

[customscript]techrocks_custom_script[/customscript]

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх