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

1. Команда.

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

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

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

Итого: хотите хорошие процессы - набирайте команду под себя. Если не дают - ищите место, где дадут.

2. Общая кодовая база.

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

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

Итого: хотите хорошие практики - в них не должен вмешиваться никто снаружи. У вас обязана быть как минимум своя кодовая база, в которую ни у кого больше доступа нет.

3. Техдир и топ-менеджмент.

Это вообще классика. Чем слабее менеджмент, тем меньше у вас получится сделать.

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

Но вот более продвинутые и важные практики и идеи вам могут и поломать.

3.1. Работа со скоупом.

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

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

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

3.2. Культура.

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

Другой культурный аспект - это бюрократия. Это не только отчёты, оценки и прочие параноидальные обязательные процедуры. Это ещё и деление на функциональные команды: команда аналитики, команда тестирования, релизная команда, команда внедрения, команда сопровождения, команда devops. Мало кто задумывается, что такое деление - это тоже элемент бюрократии, создающий препятствия на пути движения информации и решения проблем.

Хороший управленец обязан быть мягким, аккуратным и поддерживающим. Его работа должна быть направлена на обход всех условностей и препятствий на пути к решению проблемы. Он должен стремиться сгруппировать участников процесса в небольшие крепкие рабочие коллективы, объединённые одной целью и ответственностью. Хорошая культура проявляется в заботе о сотруднике, его мотивации, интересах, комфорте и психологическом состоянии.