Всем привет!
Хотел бы поделиться некоторым количеством мыслей и выводов, которые я сделал, работая на такой непростой должности, как teamlead команды разработки.
Вообще, мой путь в ИТ начинался довольно спонтанно и я бы даже сказал, странно.
Преамбула
Чуть меньше года назад мне в Телеграмме позвонил коллега, с которым мы давно знакомы и который трудится в должности Head of IT в нашей компании. Коллегу зовут Слава.
И у нас состоялся примерно такой разговор:
С: Привет! Как дела?
Я: Привет! Всё по-старому, много дел, зашиваемся. Объекты, сроки, люди горят. Жуть, словом!
С: Ага, ага, понятно, да, ясно! Слушай, а как к ИТшечке относишься?
Я: Слав, ну, никак! Кибернетика эта ваша! Ничего не понимаю, сложно представить, слабо представляю, кто там работает и чем занимается.
С: Не хотел бы попробовать?
Я: Влезть в 31 год куда-то, где я нихрена не понимаю? Я? Человек у которого сто тысяч дел, вот-вот родится дочь и который работает по 13 часов в день, потому что жалеет подчинённых и пытается им помочь?..
Я: Конечно, давай…
Я думаю, что важно дать небольшое пояснение.
Я довольно давно работаю на существующем и по сей день месте работы. Если ничего не путаю, то порядка 8 лет (надо уточнить в Кадрах будет, кстати). Я пришёл работать сюда… Короче, простым водителем.
Карьера
Шаг 1. Водитель
Ездил от поставщиков на склад, оттуда на объекты, потом в офис, потом к поставщикам и так по кругу до бесконечности.
Именно тогда я понял, что моя сильная сторона, если хотите, талант- это общение и коммуникации, что называется, ртом.
На самых разных уровнях: от вредного охранника, который не увидел пропуск на мою машину и кладовщиков, которые вообще всё перепутали и отдали не тот заказ, до генерального директора, который задаёт мне вопросы по поводу просроченных оплат с нашей стороны (такое бывало, когда контрагент небольшой и генеральный директор занимался и оформлением УПД и прочих СФ) или бухгалтера, который не принимал доверенность из-за того, что я её заполнял при них.
Именно тогда я начал совершенно отчётливо понимать, что почти всегда и почти обо всём можно договариваться с людьми. Важно ловить настроение и понимать, что именно не так в той ситуации, в которой ты оказался. Как можно решить, что сказать, с какой интонацией, с какой скоростью и серьёзностью надо проговорить какие-то вещи, чтобы ситуация решилась в мою пользу.
Тезис №1
Надо учиться не использовать инструменты, приёмы, уловки или какие-то ещё инфоцыганные ухищрения, а контролировать себя, слышать людей и строить диалог таким образом, чтобы твой оппонент начал видеть в тебе не оппонента, а союзника (извиняюсь за высокопарные выражения. Так чуть проще понять, что имею в виду).
Мы тут, вообще‑то, не меряемся красноречием, а проблемы решаем.
и тут же
Тезис № 2
Избитая фраза «Признавать свои ошибки» как‑будто потеряла хоть какой‑то привкус прикладного применения в современном мире. Я считаю, что надо признавать чужие в первую очередь. Очень полезная штука как в жизни, так и в работе. Пусть даже это признание будет понарошку. Что‑то вроде: «Да, да! Ничего страшного, что вы не подготовили товар к отгрузке (Страшно! Очень! Это критичеки важно! Время 17:00, и я на другом конце города должен быть до 18:00! В пятницу!).
Но тут Ваши нервы и попытки ускорить бедного раздолбая‑кладовщика ещё больше введут его в ступор, он начнёт тупить совсем уж бессовестно и сильно, и Вы не получите ничего вообще.
Отвлёкся! Так вот!
На такой работе я проработал примерно полтора года и мне стало тесновато. Пообщался с начальником и…мы взяли в штат другого водителя, а я уселся на нашем маленьком складе наводить порядок.
Шаг 2. Начальник склада
Сначала было скучновато без такого потока взаимодействий, но потом я нашёл прелесть в самом процессе наведения порядка. Я придумал учёт (1С у нас тогда на складе не было, она была только в бухгалтерии) с помощью онлайн таблиц. Изучал формулы, их прикладное применение и примерно через пару‑тройку месяцев склад был идеален. Не боюсь тут себя перехвалить, потому что получилось на самом деле хорошо.
У нас появились транзитные ячейки, «удалённые склады», излишки. Я снимал остатки и закупки формировали свои запросы, снимая сначала остатки со склада.
Всё стало предсказуемо и очень прозрачно. Любой сотрудник в любой момент времени был в курсе, что же у нас там по ТМЦ (товарно‑материальные ценности).
И...мне стало тесновато!
Пообщался с начальником и…мы взяли в штат другого кладовщика/начальника склада. Я же уселся уже в кресло помощника менеджера по снабжению.
Тезис №3
Надо общаться. Ну, надо общаться. И с боссами тоже! Вернее, с ними в первую очередь. По самым разным вопросам и на разные темы, но это надо.
Но то ли мы устроены как‑то так, что «поближе к кухне‑подальше от начальства», то ли у нас какие‑то базовые настройки такие, что нам, ну, вот никак вообще неудобно (плохо, нелепо, не к месту) подойти и задать вопросы, которые интересуют. Может «так принято»...
Чтобы было проще браться за вопросы, которые Вас касаются напрямую, как мне кажется, надо перестать думать так, как Вы думали, расшориться и посмотреть вот с какой стороны.
Вставочка- немного про разговоры с боссом
У Вас есть работа. Работа- это когда Вы меняете своё время на что-то. Чаще всего на деньги ?. То есть, продаёте.
Эта метрика ясна, понятна.
Теперь взгляните не как сотрудник, а как собственник (или кто у Вас приниматель решений по вопросам Level UP-ов и прочих денег). Верно! Собственник покупает у Вас Ваше время.
Все хотят сделать это как можно более выгодно, не правда ли?
Решение, которое я для вывел в сухом остатке- это общаться.
Важно не выпрашивать, а взвешенно и уверенно говорить, что Вы научились делать, что хотели бы делать в дальнейшем.
Также, не между делом, а прямо озвучить, что это нужно Вам не только для карьерных успехов, а для увеличения доходов. Да, прям для денег. В моей карьере такие разговоры помогали расставить точки над i.
Помните, кстати, что любой Ваш босс- это такой же человек (почти всегда). И он тоже избегает неудобных вопросов и разговоров.
Шаг 3. Помощник менеджера по снабжению
Я начал заниматься деятельностью, которая, как мне казалось, была соткана из моего предыдущего опыта в этой организации.
Тут тебе и разноуровневое общение, и понимание номенклатуры, и стремление к порядку, к соблюдению сроков и прозрачности!
Тезис №4
Всегда-всегда старайтесь избегать “секретиков”. То, что у Вас происходит, должно быть на виду всегда. Бóльшее количество косяков из-за непрозрачности. Во всяком случае, именно недоговорённости были причинами дурацких проблем (например, когда 2 или больше человека делали примерно одно и то же, тем самым задваивая работу и получая в финале 1 результат).
Собирайте совещания с коллегами, другими линейными руководителями, подчинёнными (про них напишу чуть позже), с другими отделами. Все должны быть в курсе всего.
Так вот.
Как уже говорил, я начал заниматься вещами, которые мне были близки: налаживал, чинил и придумывал. Начались задачи куда более серьёзные, чем просто пообщаться, начались деньги, дебиторские задолженности, договоры поставок, сроки, доп.соглашения и гарантийные письма, и много чего ещё.
Я был воодушевлён, признаюсь. Меня радовало, что я чего-то там решаю, на что-то влияю. И по причине того, что мне, как мы уже выяснили, периодически становится тесно, я довольно быстро дорос до полноценного менеджера по снабжению.
Мой дебютный проект, который я начал и не очень, кстати, успешно закончил, подарил мне 100 очков опыта вообще по всем процессам, думаю, которые вообще только возможны в коммерческой организации (вот от вопросов АХО до юридических вопросов и бухгалтерии).
И со временем я стал ведущим менеджером по снабжению.
Сколько допущено ошибок я даже не возьмусь считать, но я всегда находил в себе хоть чуть-чуть сил на честность и говорил, что у меня не получилось.
Тезис №5
Попытайтесь научиться любить время и дарить его всем как можно больше. Себе в первую очередь. Это не эгоизм! Эгоизм- это когда кто-то хочет, чтобы Вы делали так, как ему надо. А делать что-то так, как надо Вам- здравый смысл.
Простите за долгое начало, осталось совсем чуть-чуть!
За время моего развития и компания развивалась, конечно. Росло число сотрудников, масштабы объектов, уровни сложности и, конечно, бюджеты.
Когда я устроился компания состояла из 13 человек, а на сегодняшний день их 500+.
Считай, развивались вместе ?
Конечно, в определённый момент мне и в должности ведущего менеджера по снабжению стало тесно и мы пообщавшись с руководством пришли к выводу, что я делаю с нуля административно-хозяйственный отдел. Что ж, у бизнеса есть потребность, у меня есть энергия, силы и идеи.
Ну и, собственно, отдел был создан. Были наняты сотрудники, придуманы процессы, сделаны бюджет и регламенты. Всё шло ровно и хорошо. До момента звонка Славы (если забыли- это тот звонок из начала статьи).
ИТ
На своё первое ревью я ехал так. Вызвал такси с объекта, доехал до аптеки. Купил Глицин в шипучке, бутылку воды. 2 таблетки Глицина закинул в бутылку, выпил, вызвал такси и поехал на свой первый в жизни дейли.
Что могу сказать. Весь мой опыт и знания, которые я копил очень долго (у меня трудовому стажу в этом году 16 лет) как-будто вышел из чата.
Вот совсем.
Я сидел и смотрел на молодых людей, которые что-то говорят, над чем-то смеются и я, который вообще нифига не понимал просто сидел, молчал и улыбался. Честно сказать, я и сейчас, спустя почти год, не всегда понимаю, о чём идёт речь.
Слава меня мимоходом представил примерно: «А это у вас там Иван, он типа тимлид.»
Что ж, спасибо, Слава:)
Я думаю, что период адаптации достоин отдельного повествования, поэтому его пропущу.
С какими проблемами и сложностями столкнулся, когда чуть‑чуть освоился. А на самом деле с весьма простыми:
Сложная коммуникация или отсутствие коммуникации в срезе Бизнес-Продакт-Разработка;
Плохо описанные или не описанные вовсе задачи для разработки;
Непрозрачные процессы формирования задач (что/как должно работать/зачем вообще надо/как будет сочетаться с тем, что уже есть и т.д.);
Нерегулярные встречи внутри разработки;
Неопределённость;
Отсутствие сроков выполнения задачи;
Неполная команда;
И ещё всякого а-ля командное настроение, организационные вопросы и прочее.
Поскольку я не только управлял командами, но и формировал команды (правда в других отделах и сферах, если угодно), я отчётливо понимал, что мне нужен прикладной опыт того, как работает разработка и тут я совершил первую ошибку.
Ошибка
Я начал изучать информацию, которую находил в интернете. Всю. Любую. Много.
Выбирайте тщательно, что читать и на что обращать внимание. Отчасти могут помочь книги «Как пасти котов» авторства Дж. Ханк Рейнвотер и «Мама, я тимлид» Марины Перескоковой. Там можно найти ответы на некоторые вопросы, которые возникают в самом начале пути, если у Вас нет опыта руководства и некоторые рекомендации.
Например:
Как привыкнуть к роли руководителя
Как руководить собой
Как организовать успех
Почему не надо замалчивать успех
Как и зачем надо делиться задачами
Как продумывать нагрузку
Потом я отказался от столь шквального получения информации и решил для себя, что лучший для меня вариант- это планомерное погружение, чтобы избежать кессонной болезни.
Я честно на одном из дейликов сказал команде, что не понимаю в том, что они делают, но готов вникать, параллельно помогая с процессами внутри команды. То есть у нас получился неплохой симбиоз- я чиню процессы, команды чинит мои хардовые скиллы.
Опять же, очень важна честность и прозрачность. Я такое прям проповедую.
Итак, наши проблемы.
1. Сложная коммуникация или отсутствие коммуникации в срезе Бизнес-Продакт-Разработка.
Поскольку я давно работаю в организации, то у меня не было каких-то особых проблем с тем, чтобы объяснить команде, почему Генеральный директор выдаёт именно такие распоряжения или почему мы начинаем делать те или иные вещи, вот, именно сейчас.
Важно отметить, что мои ребята находились в небольшом вакууме. Его, собственно, и разгерметизировал. Я долго и терпеливо отвечал на вопросы. Признаться честно, делал это с удовольствием.
Пообщался с продактом и попросил его подготовить красивую презентацию, на которой он отобразил все лиды, деньги с продаж, показал roadmap, ответил на вопросы.
Как следствие, у разработчиков, которые были заключены на 3 этаже появилась информационная форточка, откуда дует пониманием.
Итог- команда не просто работала в каком-то там юридическом лице, а в понятной крутой организации, которая понятно чем занимается, что делает, какие занимает позиции на рынке и зачем они, то есть разработчики, трудятся.
2. Плохо описанные или не описанные вовсе задачи для разработки
Не буду долго описывать, как решился этот вопрос. На самом деле мы просто взяли в команду крутого бизнес аналитика со столь нужным нам опытом системного аналитика.
И у нас починилась поломка формирования описательной составляющей задач. Мы и до сих пор стремимся к тому, чтобы получая тасочку в работу, программист говорил: "Угу, понятно" и просто приступал к реализации.
Безусловно, предела совершенству нет и мы постоянно стараемся сделать как можно лучше описание, помятуя о том, что лучшее- враг хорошего.
Итог - задачи обрели своего переводчика с менеджерского языка на язык технический. Стали понятными исполнителям.
3. Непрозрачные процессы формирования задач (что/как должно работать/зачем вообще надо/как будет сочетаться с тем, что уже есть и т.д.).
Если честно, мы до сих пор работаем над этой вещью.
Это сложно. Сложно потому, что в наших реалиях Продакт - это своего рода Генеральный директор продукта, который отвечает за деньги, за репутацию нашего продукта. Он проводит очень много время на встречах, например, с отделом продаж и времени на то, чтобы объяснить, зачем мы именно сейчас делаем ту или иную вещь катастрофически не хватает, но... дьявол, как известно, в мелочах!
И даже тут придумался способ, который известен как Product refinement document. Если вынести основное, то при формировании задач наш любимый Продакт как бы отвечает на вот такие вопросы:
Если немного расшифровать, то документ с требованиями к продукту (PRD) - это документ, содержащий в себе все требования к конкретному продукту.
Он описан так, чтобы участники команды (разработка, дизайн) могли понять, что должен делать продукт или функциональность. Как правило, PRD НЕ ДОЛЖЕН предвидеть или диктовать, как продукт будет это делать.
С помощью таблицы выше предлагается описывать глобальные функциональности или функциональности затрагивающие большое количество элементов системы, редизайн различных флоу, страниц или вкладок. Различные мелкие исправления с помощью этого документа описывать не надо.
Итог- появилась прозрачность не только каких-то отдельных элементов для каких-то отдельных частей команды, но и в целом все всё начали понимать и видеть. И глобальный извечный вопрос: "НАХРЕНА ЭТО ВООБЩЕ НАДО" стал звучать всё реже :)
К тому же качество кода растёт, поскольку разработчик стал видеть чуть шире
4.Нерегулярные встречи внутри разработки
Мы работаем по двухнедельным спринтам и у нас было планирование. По нашей традиции проводилось оно по четвергам, каждые 2 недели (то есть аккурат в момент окончания старого спринта и начала нового).
Обычно планирование длилось 2-3-4 часа и выматывало людей, которым задачи планировались и которые эти задачи планировали.
У UX/UI в январе висели сделанные ими в ноябре задачи, а QA почему-то были вообще в стороне. Непорядок!
Что сделалось:
а) По средам, перед планированием, начали проводить предпланинги (с нэймингом у меня плохо, факт). Предпланинг- это встреча по стекам (то есть дизайн отдельно, бэкенд отдельно, фронтенд отдельно), которая проводится до планирования с целью ознакомления разработчиков с задачами. Также на этих встречах Продакт отвечает на вопросы, если таковые возникают, дизайнеры показывают, чего они там нарисовали (дизайнеры просят говорить не нарисовали, а напроектировали). На всех встречах присутствуют тестировщики, которые могут сразу рассказать, что может сломаться, что на что может заафектить, на что надо обратить внимание.
Типичный предпланинг состоит из:
- Продакт
- Бизнес аналитик
- Тимлид (это я)
- Тестирощик
- Дизайнер
- Разработчики стека
И вся эта компашка уже снижает уровень непрозрачности вообще до минимума.
Приятный бонус- вся команда в курсе, что делает вся команда и время планирования сократилось. Сильно. Самый короткий планинг занял у нас 13 минут. Потому что все всё знают, все оценили свои задачи (стоит сказать, что мы используем оценку сложности задачи- это sprint point. В спринт у разаработчика не может быть более 16 SP и не может быть двух задач по 8 SP).
b) Дизайн-ревью. Каждый понедельник, в 14:00 мы (тимлид- это я, Продакт, бизнес аналитик, дизайнеры, тестировщик и... ведущие специалисты каждого стека) собираемся и смотрим, что же там нарисовали напроектировали дизайнеры. Что-то отправляется на переделку, что-то проваливается в работу.
Зачем тут разработчики и тестировщик? А это потому, что у наших крутых дизайнеров богатейшая фантазия :)
Итог- не могу сказать, что стерильно, но стало в разы лучше с понимаем того, что мы все тут делаем и за что нам платят. Никаких секретиков между стеками.
5,6 Неопределённость, Отсутствие сроков выполнения задачи
Соединю эти пункты. Вообще, неопределённость определённо (опа, каламбурчик) сходит на нет. К сожалению, это небыстрый процесс. Я не сильно топлю за то, что мы должны к какому-нибудь понедельнику или началу нового месяца иметь 100% определённость в том, что у нас происходит. Всё-таки к нам спускаются задачи от бизнеса иногда и меняются приоритеты в дорожной карте, что не способствуют продуктивности. Но у нас такие данные. С ними и работаем.
Про отсутствие сроков выполнения задач, на самом деле, ответил выше. У нас появились SP, у нас есть адекватный и причёсанный roadmap. Разработка с хладнокровностью Лаврентия Берии разбирает свои задачи. Превращением эпиков в атомарные таски занимается бизнес аналитик.
Итог. Продакт шарит и доверяет разработке, разработка ещё как шарит и доверяет продакту.
7. Неполная команда
К решению этой проблемы подошёл со всей ответственностью и из 9 мы превратились в 17 человек.
Команда стала большая:
- 1 тимлид (это я, кстати) раньше не было
- 3 мобильных разраба (их и было 3)
- 4 тестировщика (было 2)
- 2 дизайнера (был 1)
- 2 бэкенда (был 1)
- 4 фротнендера (было 2)
Сейчас всё хорошо :)
8. И ещё всякого а-ля командное настроение, организационные вопросы и прочее
Как и говорил, я довольно давно работаю в организации и совершенно просто и несложно решаю вопросы своих ребят в бухгалтерии, у юристов, по больничным и отпускам. То есть я стремился сделать так, чтобы разработчики разрабатывали, а не ходили куда‑то, чтобы получить справку с места работы:)
Командное настроение чинилось своим примером. Я подходил и подхожу к каждому периодически с вопросами: «Всё ли получается? Не нужна ли помощь?»
Каждый день я здороваюсь и прощаюсь со всеми за руки. Прям обхожу каждого.
Я хвалю своих ребят на каких‑то общих встречах публично. А, вот, ругать (ну, как ругать, по факту срыва срока, допустим) всегда предпочтаю 1 to 1.
Собственно, к чему весь этот текст.
Мой вывод, в общем, в том, что если ты кем-то руководишь, то тебе, как-будто, не очень нужны какие-то инструменты. То есть они, конечно, нужны, но всё строится на общении, на адекватности, на доброте и дружелюбности. Также важно понять, когда тебе сели на шею!
Также я убеждён, что сначала ты взаимодействуешь с человеком. С его хотелками, с его состоянием и настроением, а уж потом только с коллегой или подчинённым.
Кстати, про настроение. Я также за много лет управления убедился, что надо управлять эмоциями. Важная штука, попробуйте!
Всем спасибо и пока!
