В статье я расскажу о моём опыте работы на должности тимлида в компании по разработке сайтов. Чтобы всем было полезнее и проще читать, статья разбита на главы, каждая из которых рассказывает об одной отдельной проблеме и её решению. Хотя по возможности будет сохранена хронология событий.
Надеюсь, что описанный ниже опыт станет для кого-то чужими граблями, а в комментариях я и сам почерпну что-то от более опытных коллег.
Но никаких названий, компаний, клиентов, имён коллег. Договор о неразглашении, все дела.
Предыстория. Как и где я вообще стал тимлидом
Это первая фирма, куда я пришёл сразу тимлидом. Для меня это был качественный скачок в плане карьерного роста. На прошлую работу (1,5 года) я пришёл миддлом и вырос там до сеньора. Но градации разработчиков слишком субъективны и часто зависят лишь от компании, где они работают. Какое-то время я много изучал вопрос оценки программистов и по сути всё свелось к тому, что если “взяли миддлом/сеньором/старшим — стал миддлом/сеньором/старшим”. Когда я начал искать работу, мне бы хватило и позиции сеньора (и её я искал), но предложение тимлидства меня перекупило и немного польстило.
Собственно при самом поиске вакансий уже на второй день меня сманили в столичную фирму, которая занимается разработкой сайтов на Битриксе (так что дальше всё происходит на фоне разработке сайтов на Битриксе). Я же наоборот давно мечтал уйти от Битрикса, но возможность самореализоваться в новом качестве и хорошая зарплата не оставили мне шансов отказаться.
Забавный факт: единственным условием при приёме меня на работе было то, что я могу сам выбирать технологических стек, но нельзя ни в коем случае не отказываться от Битрикса, если на нём настаивает клиент.
На новом месте
На новом месте оказался очень хороший начальник-технарь, плохой менеджер, джун, миддл и несколько действительно больших проектов на Битриксе. Довольно странная ситуация и я до сих пор не понимаю, как она сложилась и не схлопнулась сразу. Но возможно меня и пригласили как раз для того, чтобы всё наладить.
В первые же дни в глаза бросилось множество “детских” проблем:
- информация по проектам хранилась в головах у одного-двух человек и нигде более. Инструкций и документации тоже никаких не было, и чтобы узнать как работает тот или иной функционал, нужно было пытать того, кто его делал, если вообще мы его создавали
- каких-либо налаженных систем и процессов считай не было, всё делалось “как-то”, “по привычке”. Отсюда соответственно суета, неразбериха, срывы сроков, напряжение
- задачи ставились считай на словах. В трекерах были лишь названия задач, просто чтобы можно было залогировать время куда-то (нужно было набирать 40 часов в неделю)
- сама разработка тоже была не ахти:
- где-то что-то разрабатывалось даже вне гита
- где-то программисты по очереди правили файлы на одном сервере
- где-то были тестовые площадки, а где-то их не было (но в любом случае они не сильно помогали)
- вдобавок везде было очень, очень много говнокода. Предвосхищая комментарии, сам Битрикс тут, к сожалению, не причём
- Всё общение происходило в скайпе. Но к нему у меня просто личная неприязнь
В общем, всё очевидно плохо, улучшения можно начинать сходу, не проводя предварительных исследований. Это меня даже в какой-то степени обрадовало, так как можно с первых же месяцев влиять на показатели. Они правда ещё не считались, но из-за Парето, это пока и не важно.
К моему разочарованию процессы первые месяцы двигались довольно медленно. Во-первых, мне самому приходилось по 8 часов в день работать над клиентскими задачами, как программисту, так как рук просто не хватало. Во-вторых, в условиях такого цейтнота, довольно опасно было делать большие изменения, которые могли бы привести к путанице и к потере кода или времени.
Теперь переходим непосредственно к статье и решению проблем. Первым делом в новой компании нужно было как-то сориентироваться.
Вытаскивание информации из голов сотрудников
Когда я пришёл, я совсем ничего не знал ни о проектах, ни о клиентах, и эта информация не хранилась
нигде в текстовом виде. Поэтому первым делом, я начал вытаскивать информацию из голов коллег в тексты.
По сути в фирме, занимающееся разработкой, есть 2 больших подмножества важных и/или полезных текстов:
- инструкции, регламенты, статьи, описания функционала, пользовательские истории,...
- Задачи с их названием, описанием, комментариями, логами времени, подписи к коммитам, комментарии в коде, автотесты,...
По началу я просто просил новых коллег расписать для меня какие-то конкретные вещи из первого пункта, но все конечно ленились, тем более, что инструкцию писать это не фичи пилить. Но поскольку у меня поначалу был ещё совсем незамыленный взгляд и мне приходилось изучать проекты, видя их впервые, я просто начал транслировать свои исследования в текст, создавая тем самым инструкции и описания функционала.
Так же повезло, что в то же время фирма начала активно переезжать на scrum (просто совпадение), менялось рабочее ПО (тоже совпадение), соответственно с нуля создавались бизнес-процессы. И у меня почему-то изначально был большой авторитет в глазах коллег. Поэтому я просто начал писать регламенты самостоятельно (в рамках компетенции) и перестраивать на них ребят, то есть по сути просто диктовать правила и быть примером их исполнения.
Решение же проблемы с постановкой и ведением задач затянулось не на один месяц. Это оказалось бутылочным горлышком и в последующих главах я ещё не раз подниму эту тему.
На момент начала моей работы менеджер ставила задачи ужасно. Пример: название задачи — “Исправить баг на сайте” и всё: ни какого-либо описания, ни скринов, только название и отсылка к проекту. Были конечно попытки донести принципы SMART и важность описания задач до менеджера, но все начинания разбивались об “У меня нет времени расписывать задачи”.
Одно время я пытался перенять часть ответственности за постановку задач, но тут иронично, что у меня на это тоже не хватало времени, так как практически всё время я писал код.
А вот смежную проблему получения актуального статуса задач в произвольный момент времени мы решили в обход, через координационные созвоны и планы на день.
Пополнение штата, интеграция в команду
Практически изначально было понятно, что людей катастрофически не хватает (я сам полный рабочий день писал код, но мы всё равно не успевали).
Первым решили взять фронта, так как оба прогера в фирме были беками (и я себя тоже отождествлял больше с бекендом), а задач, особенно по вёрстке, хватало, и на горизонте ещё начали маячить задачи по реакту и vue.
Тут очень повезло, что у меня был (и есть) друг фронт, который в то же самое время начал подумывать уйти с фриланса, поэтому мы смогли быстро заткнули вакансию, а я получил премию за приведение сотрудника (ещё один плюс начальству, до этого не видел hr-премии).
Почти сразу же после фронта нашлись 2 бека. И где-то в это же время ушёл джун (чей код меня выбешивал ещё несколько месяцев после его ухода).
Итого в разработке сложилась следующая ситуация:
- один “старичок”
- я
- трое абсолютных новичков
- работа ещё не налажена
- часть знаний уже потеряна
Закономерно, что на меня, как на тимлида, сразу посыпались десятки вопросов от новичков. В основном это были вопросы по жизненному циклу кода (где писать код, как показывать, куда его отправлять потом, как собирать релиз), по ведению задач (как брать задачи в работу, как показывать статус, как определять приоритеты) и по работе с гитом. Плюс ребята ещё пытались задавать вопросы “Как работает А?”, “Есть ли у нас на сайте В?”, но практически всё в тот момент сводилось лишь к необходимости изучать код.
Первым делом важно было дать прогерам возможность в принципе работать и писать код самостоятельно. Я проводил с ними ознакомительные беседы, отвечая на их вопросы, потом конечно же решил свести все вопросы и схемы в статью, которая затем переросла в лекцию, а потом и вообще в совершенно новую схему работы в фирме, о которой я расскажу в следующей главе.
Здесь же стоит сказать пару слов о процессе найма в нашу фирму, которая работает до сих пор.
Процесс найма
Во-первых, у нас есть бонус за привлечение сотрудника, что довольно хорошая практика.
Во-вторых, мы решили не устраивать экзамен на собеседовании, а давать очень объёмную задачу, приближенную к нашим повседневным. Это удобно тем, что временные затраты на найм снижаются лишь до поиска подходящих резюме и лёгкого интервью с соискателями для проверки на адекватность и рассказа про тестовое задание, и, конечно, непосредственно проверки задания.
Задачу на самом деле может решить и джун за пару вечеров, объёмной её делает большая свобода в реализации, улучшениях и напрашивающихся фишках. Именно эта гибкость реализации помогает нам оценить уровень соискателя. Мы сразу говорим, что самое главное для нас это лишь уложиться в сроки решения задачи (называет сам исполнитель) и в конце показать рабочий код в репозитории. Мы не оговариваем использование каких-либо подходов и технологий, их выбирает сам исполнитель, но чтобы пойти на встречу и дать подсказки, мы перечислили возможные улучшения списком, как задания со звёздочкой, например, работа через аякс, доп. валидация на бэке, защита от спама, оформление в виде модуля, использование D7, ...
Итого:
- по резюме и интервью мы можем судить о характере человека
- по сроку исполнению задачи, факту работоспособности кода и использованию гита мы принимаем само решение о приёме на работу
- по качеству выполнения мы определяем уровень и соответственно зарплату, которые можем предложить
- плюс уже на тестовом задании мы показываем, какие задачи придётся решать на новом месте
Налаживание системы разработки и поставки кода
На тот момент у нас было несколько проектов, которые разрабатывались довольно хаотично:
- где-то на бою был мастер, где-то другая ветка
- где-то были тестовые площадки, где-то нет
- а если и были, то адреса у всех разные
- гит в принципе использовался слабо и со скрипом
- изменения в базы данных вносились вручную
- …
Сначала я маленькими порциями пытался исправлять ситуацию, чтобы программистам нужно было меньше переучиваться, и соответственно путаться. Например, вынул папку bitrix из под гита, переименовал основную ветку обратно в master.
Но когда к нам пришло большое пополнение, ситуация стала критическая. Приходилось много объяснять, напоминать и писать нелогичные инструкции, так как текущая структура разработки была ну совсем не интуитивно-понятной.
Я не любитель инструкций как таковых, считаю, что их наличие само по себе индикатор проблемы, поэтому было решено создать общую для всех проектов систему, которую нужно понять один раз и которая самой своей структурой убирает множество проблем и вопросов.
Система заключается в следующем:
- у каждого разработчика есть удалённая личная рабочая площадка, где он работает
- есть площадка, где накапливается функционал для следующего релиза
- при необходимости есть демонстрационная площадка для демонстрации всяких зачатков функционала
- весь код для одной задачи держится в одной отдельной ветке, где название ветки равно названию задачи в трекере
- чтобы залить код на общую площадку, ветку нужно просто смержить куда-надо и запушить
- изменения в базах данных хранятся в виде файлов миграций в ветке задачи
Я провёл большую лекцию на тему этой системы, и мы начали пилотный переход на неё на одном проекте, куда как раз кинули новоприобретённого сеньора.
Процесс перевода всех проектов на эту систему, конечно же, затянулся (например, на одном проекте мы мистическим образом не смогли переехать в мастер с первого раза), и он до сих пор продолжается, но по итогу мы получили как минимум:
- возможность релизить только нужные задачи, а не релизить вместе с полезным кодом недоработанный функционал
- делать релиз задачи без привлечения автора кода
- параллелить работу над проектом между исполнителями
- не терять код
- тестировать функционал изолировано от другого и не стопорить при этом работу прогера
Всего этого раньше просто не было. Плюс не нужно теперь объяснять лишние тонкости работы с гитом или тестовыми площадками новым прогерам, так как всё универсально и интуитивно.
Scrum, коммуникации, регламенты
Конечно, в статье я намеревался рассказать о том, как я помогал в развитии фирмы, будучи тимлидом, но нельзя говорить о развитии нашей компании, не упомянув нашего начальника и его инициативы, иначе это будет не совсем честно.
Во-первых, он внедрял scrum и на момент моего прихода процессы в компании начали очень активно переделываться. Также в этот момент перевёл её из Битрикс24 в Джиру.
Скрам конечно же привносил больше ритма в компанию и уменьшал хаос. За переобучением менеджеров, их исполнением координационных созвонов, открытием/закрытием/планированием спринтов следил сам начальник, как старший в этом звене.
Также он много работал над самими менеджерами, в особенности над тем как они общаются с клиентами и программистами, так как большАя часть их работы (но, конечно, не ограничиваясь) в том и состоит — общаться: изолировать программистов от клиентов, транслировать пожелания клиентов в задачи в беклоге и в спринтах, находить и перерассказывать пользовательские истории. Всё это вылилось во множество регламентов: по общению с клиентами, по постановке задач, по работе с беклогом, по принятию в работу багов. На коммуникации был сделан сильный упор и управляющее звено действительно показывало прогресс.
Сам переход на скрам, конечно же, очень тяжёл и на момент написания статьи, мы ещё не стали его профессионалами, хотя к этому всё идёт. И я очень рад, что получил множество новых знаний по гибким методологиям и продуктам атлассиана.
Новый менеджер. Тексты, постановка задач, беклог
В какой-то момент пришёл ещё один человек, который должен был помочь нам совершить качественный скачок — новый менеджер (до этого у нас был один).
Этот момент я не ожидал, так как проектов и программистов у нас было не так много и в теории должно было хватать всего одного менеджера. Данное звено было слабым местом в компании, но мы пытались решить эту проблему развитием существующих кадров. Просто так совпало, что один отличный менеджер, которого я хорошо знаю, решила сменить работу, об этом узнал мой начальник, так как она внезапно собеседовалась к нашим подрядчикам и я обмолвился об этом забавном инциденте, и мы позвали её к себе. Ещё одна премия)
По началу новый менеджер повторяла часть моего пути, так как столкнулась с теми же проблемами (ничего не знает и негде почитать) и начала всё по новой, но с тем отличием, что она не трогала код, инфраструктуру разработки и навыки прогеров, а работала с постановкой задач, общением с клиентами, чисткой беклога, а также усердно вытаскивала информацию из головы старого менеджера. В частности, первым делом вытащила список контактов клиентов и подрядчиков.
Команда уже была с ней знакома, так как мы как-то раз приглашали её лектором, чтобы рассказать нам про контроль времени. Плюс задачи стали ставится более подробно, негатива она не добавляла и не передавала его от клиента, статусы у задач стали более актуальными в любой момент времени. Поэтому мы сразу же возложили на неё большие надежды.
Первые недели они с начальником наводили порядок в беклоге на одном проекте, в частности нашли просроченный на 2 месяца и ещё не начатый эпик. Кроме этого в принципе выплыло много задач, которые нужно было сделать месяц назад. Хорошо конечно, что беклог был почищен, но это было сделано слишком поздно.
Сама она правда “вешалась” от бардака и не раз порывалась уйти, но менеджерское звено мы так или иначе сильно улучшили. Задачи стали реже теряться в беклоге, программисты стали реже переспрашивать.
Мораль истории будет в конце.
Кризис
Спустя почти полгода после начала работы мне нужно было уйти в отпуск. К слову сказать, об отпуске я договорился ещё при устройстве на работу, так как это планировалось как свадебное путешествие, поэтому период моего отсутствия был известен сильно заранее. Но я всё равно, конечно, нервничал до последнего, потому что мы только недавно перестали работать “на износ”.
В неделю перед отпуском я закончил делегирование обязанностей, научил выбранных людей выполнять специфичные дела вне кода, закрепил за каждым программистом ответственность за конкретный проект, закончил или передал все свои текущие задачи (я тогда всё ещё программировал большую часть дня). Ничего не предвещало беды в середине июля.
И в первые дни отпуска тоже ничего не предвещало беды.
А потом произошёл кризис.
На одном проекте у клиента кончилось терпение из-за того, что его ожидания выполнения задач (сроки, список, приоритеты) не соответствовали делу. Мы и сами это заметили не так давно при полной переработке беклога и активному общению с клиентом (глава про нового менеджера), но было слишком поздно.
А на втором проекте наконец-то приняли очень большую и долгожданную задачу, закончили тестирование и зарелизи её. Но новый функционал внезапно повалил боевой сайт под неподъёмной нагрузкой, и миддл с фронтом неделю ничего не могли с этим сделать. Естественно этот клиент тоже начал материться и подумывать отказаться от наших услуг.
Первая проблема не относилась непосредственно к разработке, поэтому я активно участвовал в исправлении ситуации на втором проекте. Хотя я и не мог весомо помочь, так как был в другой стране без интернета и ноутбука. Максимум моей помощи был в консультациях прогеров, особенно, когда уже купил интернет.
Ответственный за проект бэк перерабатывал целую неделю каждый день в попытках завести новый функционал в боевом окружении и вместе с фронтом разбирался в кодовой базе vue, где большую часть писали не они двое (я как раз, кстати).
Коллега попал в ужасную ситуацию — работал до часу ночи всю неделю, сильно стрессовал, но и на него же по итогу свесились все шишки, в особенности из-за того, что он всё это время повторял “починю к обеду / к концу дня / к ночи / к утру”.
Ситуацию по итогу смогли исправить, но всё это вылилось в то, что пока мы решали его дальнейшую судьбу, он сам написал заявление об увольнении, так как устал такого стресса.
Самым странным было то, что судя по общению с ребятами, всё это время, они действительно работали, и даже довольно быстро нашли проблемное место, но на решение понадобилось множество десятков часов и столько же потом на исправление появившихся поломок второстепенного функционала.
Мы много думали о том, почему сложилась такая ситуация и как их предотвращать в будущем. Явно вскрылся недостаток профессиональных навыков и мастерства оценки задач, поэтому для профилактики мы решили ввести добровольно-принудительное подтягивание программистов внутри фирмы. На необходимость этого ещё намекало и то наблюдение, что у прогеров с сайд-проектами не возникали похожие проблемы.
Развитие программистов
Критично важным было повышать квалификацию программистов. Стагнация это в принципе маленькая смерть (и уже один реальный прецедент увольнения), к тому же уже начали проявляться проблемы из-за недостаточности знаний или умений:
- накапливался технический долг
- ребята часто жаловались на проблемы с гитом
- исправления непредвиденных багов занимало очень много времени
- новые технологии внедрялись очень тяжело
- встреча с чужим кодом была прямо преградой
Кто-то развивался самостоятельно, кто-то нет, а кто-то вообще ушёл не в те дебри, хотя это может быть и полезно. Поэтому нужно было развивать программистов централизованно силами компании.
Кодревью
Я пытался почаще ревьюить код, но выхлопа от этого было недостаточно. Ребята, конечно, читали мои комментарии, но замечания повторялись раз за разом.
Лекции
Ещё одной идеей было проведение лекций. Например, однажды я собрал все примеры говнокода, которые находил при кодревью, в один большой файл с объяснениями каждого случая и рассказал о них на созвоне. Такое прямое обучение, конечно, было более полезно.
Кстати, именно в формате лекции я научил ребят работе со vue, который мы потом много использовали.
Всего мы провели не так много лекций, где-то около 5. Во-первых, никто из других программистов так и не подготовил свою лекцию. И проблем с говнокодом и превышением оценок это не решало, а они были самым главным.
Совместные сессии
Особенно меня расстраивала проблема с гитом, никогда до этого не встречал такое их количество: мерджы приводили к потере кода, решение конфликтов иногда клало сайт, файлы в коммиты иногда приходили помеченными как полностью переписанные, да и в принципе коммиты и сообщения к ним были совсем неинформативны.
Я подумал, что это из-за того, что ребята работают с гитом через консоль или ещё как-то по своему. Это привело к идее не просто созваниваться и проводить лекции, а созваниваться и писать вместе код, показывать как работать в Шторме, как делать коммиты, как решать конфликты через удобный интерфейс, как рефакторить код и между делом и просто обсуждать всякое программисткое.
И такой формат выстрелил.
Мы стараемся собираться каждую пятницу. Показываем друг другу всякие фишки в Шторме, куда вся команда, благодаря созвонам, наконец-то переехала, избавляемся от вопросов по гиту, улучшаем само качество разработки.
Плюс я верю, что такие еженедельные программисткие созвоны поднимают дух программистов, так как мы не просто разбираемся, почему из 1с пришла неправильная цена или добавляем очередной раздел с акциями на сайт, а как-то развиваемся, тесно общаемся без менеджеров и клиентов рядом, каждый немножко делится опытом и тем, что ему интересно, разбираем возникшие технические проблемы, подтягиваем отстающих. И не только я бываю на них ведущим, наоборот довольно часто отдаю инициативу и ребята сами начинают вещать полезные вещи.
Эффективность команды, оценка задач
Одной из самых больших проблем в компании было постоянное превышение сроков по задачам. Иногда среднее превышение по часам за месяц доходило до двух раз.
Проблема встала особенно остро во время моего отпуска, когда целую неделю задача с самого начала переносилась ещё на несколько часов вперёд, то есть каждые 3-4 часа говорилось “нужно ещё 3 часа”, и по итогу она заняла почти 40.
Опять же благодаря руководству мы не были в минусе и никого не увольняли, но растягивание задач отнимало у нас как минимум премии, а как максимум могло привести и к убыткам.
Мы прозвали соотношение факт/оценка выполнения работ в часах — КПД (ну как прозвали). КПД всей команды стало моим КПИ, как основная задача тимлида. Я был рад тому, что у меня появилось числовое КПИ. И моя радость усилилась ещё и тем, что в это же время я, наконец-то, перестал программировать по 8 часов каждый день и теперь мог полноценно заниматься тимлидскими делами.
Мы оооочень много думали над проблемой КПД. Явных протечек видно не было:
- программисты оценивали задачи довольно здраво
- реально над ними работали, а не просто ставили таймер
- с коммуникациями не было никаких проблем
Но потом всегда что-то шло не так и каждый раз разное:
- находился подводный камень
- итоговое решение не устраивало клиента
- отваливался какой-то смежный функционал
- при тестировании что-то пропускали и потом переделывали
- теряли время на поиск каких-то доступов
- ...
Я решил (не без интервью с каждым программистом в отдельности), что проблемы кроятся в:
- качестве оценки задач, что ребята всё-таки часто просчитываются
- в самом уровне программистов, из-за чего образуются задачи-”чёрные дыры” и исправление багов затягивается на часы. Это также могло вызывать ступор при встрече с неизвестными технологиями
- говнокоде, связанности кода. Хотя эта проблема косвенно пересекается с предыдущей
- в постановке задач, так как я часто слышал жалобы о неполноте информации в описании, плюс этот же момент мог приводить к лишним переделкам
Потом я решил провести исследование — проверил все логи времени во всех задачах с превышением оценки за последнее время. И это принесло несколько новых открытий:
- задачи изначально оцененные ровно в 1 час практически всегда были превышены
- тестирование задачи практически никогда не было заложено в оценку и часто именно оно давало превышение
- неожиданно и неприятно, но в логах времени часто упоминались проблемы с гитом. Причём большие логи, иногда по полтора часа
На основе всех этих знаний мы придумали контрмеры:
- я ежедневно лично проверяю все оценки и постановку всех новых задач, особенное внимание, конечно, уделяю маленьким задачам. Так мы боремся с неадекватностью оценки и неполнотой постановки
- переводим всех ребят в шторм, чтобы они как минимум перестали возиться с мерджами в консоли
- во все задачи закладываем время на тестирование, общение и сдачу клиенту
- проводим еженедельные созвоны узким программистким кругом, где вместе программируем, делимся знаниями, хитростями, учимся решать конфликты и рефакторить код между делом
Это всё начало довольно быстро приносить свои плоды, особенно программисткие созвоны. Например, уже после второго созвона ушли проблемы с гитом.
Кпд начал выправляться, хоть и не очень быстро. В данный момент мы всё ещё прикладываем много усилий и не перестаём изучать этот вопрос.
Чему я сам научился на новой должности
Кадры — самое важное
Ты можешь скупить все продукты атлассиана и джетбреинса, понарассказывать умные вещи, ввести кучу регламентов, договориться с клиентами насчёт схем постановки задач, но если твои коллеги саботируют регламенты, работают “по привычке” и не используют новые инструменты, то толку от нововведений нет.
Также проактивный человек всегда выгодно отличается от просто хорошего работника, хотя бы тем, что может выйти из своей “законной” зоны ответственности и не дать задаче застопориться или может предложить какое-то общее улучшение без просьбы сверху.
Личные качества важнее профессиональных
Например, у тебя может быть крутой спец, который всегда укладывается в сроки, может решить любую задачу, пишет идеальный код, но он появляется на связи дай бог 2 часа в день или внезапно берёт выходной посреди недели. Такой приносит несравнимо больше проблем, чем пользы, особенно при обнаружении багов в его задачах.
Или можно представить ситуацию, когда есть два одинаковых работника, но один из них читает профессиональную литературу и/или ведёт личные проекты, а второй нет. Изначально они одинаковы и в зарплате и в навыках, но через время второй начинает тянуть компанию вниз и факапить, а второй всё также продолжает выполнять свои задачи или даже обгонять более опытных коллег.
Ещё очень вредны моменты, когда люди отказываются брать на себя ответственность. Это выливается в саботаж поручений или мёртвой остановке задач, если с изначальным исполнителем нет связи, и/или если нужно сделать что-то потенциально опасное, например, разрешить конфликт или выполнить какие-то действие на боевом сайте.
Эмоции от коллег влияют на многое (большее, чем я раньше считал)
Многие не любят свою работу из-за стресса. Стресс может быть вызван, например, уровнем зарплаты, токсичностью коллег, глупостью клиентов, дорогой на работу, рабочими обязанностями, миллионом других причин.
Новый стресс на работу могут принести клиенты, непредвиденные обстоятельства, коллеги. Но от первого можно абстрагироваться, второе решить, а вот вечно ноющих и депрессивных сослуживцев ты будешь видеть каждый день.
Вообще чтобы мы не делали: писали код, занимались дизайном, работали с бухгалтерией, мы всё равно так или иначе работаем с людьми, и именно они больше всех влияют на наше настроение. И возможно, что именно общение с командой определяет задержится ли человек в компании или нет.
На два стула не сесть
Первое время мне приходилось писать код весь день, из-за чего я считай совсем не успевал свои чисто тимлидские обязанности, только что помогал команде в целом более менее укладываться в сроки. Но это как катить квадратное колесо, когда тебя попросили обточить его.
Ещё популярные вредные примеры перемешивания обязанностей:
- программисты долго общаются с клиентами и не укладываются после этого в сроки
- руководители занимаются распределением всех задач между исполнителями, что съедает всё их время
- контент-менеджеры пытаются править код и ломают сайт
- менеджер пытается передать жалобу программиста по коду другому программисту
1сники пытаются придумать хорошее решение
Здесь конечно не озвучены всякие постулаты о важности саморазвития или, например, гигиены труда, но лишь потому что это не новый опыт мне их открыл.
Планы
Изначально, когда я ещё только начал задумываться о смене работы, я хотел уехать на Кипр, потому что ждал от него солнца (стереотипы про Питер совсем не стереотипы), спокойствия, хорошей зарплаты, интересных вызовов и отсутствия стрессов.
Но Москва мне предложила условия, от которых я не смог отказаться (карьерный рост, зп в 2 раза больше текущей, площадку для экспериментов и почти полную свободу действий).
С другой стороны, если подумать, мы же тоже Европа. Поэтому я хочу “приближать Кипр сюда”, то есть чтобы команда:
- меньше стрессовала на работе
- перестала дико уставать
- избавилась от негатива исходящего от коллег и клиентов
- имела возможность гордиться своей работой, то есть перестать править баги и разгребать факапы, а пилить что-то крутое
когда-нибудь ушла от Битриксаиспользовала новые технологии.- ну и конечно же увеличила прибыль
Ну то есть всего того, что мы ждём от прекрасного далёко.
Часть 2
Эта статья охватила примерно полгода моей работы в новой должности. Во второй части я бы хотел рассказать о том, как мы движемся к целям с помощью:
- автотестирования, которые мы только начинаем внедрять. Странно, но почему-то на Битриксе нет достойных примеров
- избавления от наследства в коде
- дальнейшего ускорения и упрощения разработки
- того что я почерпну из комментариев
- множества других пока секретных вещей (вдруг меня мои ребята читают)
Всем спасибо за прочтение. Буду очень рад комментариям, особенно, если вы знаете более оптимальные пути решения проблем, с которыми мы сталкивались.
Всем удачи и радости в работе и жизни!
Автор: Аристов Василий
