В этой статье я расскажу о своем опыте работы руководителем группы в компании по разработке веб-сайтов.
Чтобы всем было полезнее и проще читать, статья разделена на главы, в каждой из которых рассказывается об одной отдельной проблеме и ее решении.
Хотя, по возможности, хронология событий будет сохранена.
Надеюсь, что описанный ниже опыт станет чьими-то граблями, а в комментариях я сам почерпну что-то у более опытных коллег.
Но никаких имен, компаний, клиентов, имен коллег.
Соглашение о неразглашении, всё.
Фон.
Как и где я стал тимлидом? Это первая компания, куда я сразу пришел руководителем команды.
Для меня это был качественный скачок в плане карьерного роста.
На свою последнюю работу (1,5 года) я пришел миддлом и дорос там до старшего.
Но оценка разработчиков слишком субъективна и зачастую зависит только от компании, в которой они работают. Некоторое время я много изучал вопрос оценки программистов и по сути всё сводилось к тому, что если «их нанимали на должность мидл/сенор/сениор, то они становились мидл/сенор/сениор».
Когда я начал искать работу, мне было бы достаточно руководящей должности (а я ее искал), но предложение руководства командой меня перекупило и немного польстило.
Собственно, пока искал вакансии, меня уже на второй день переманили в столичную компанию, занимающуюся разработкой сайтов на Битриксе (так тут все происходит на фоне разработки сайтов на Битриксе).
Наоборот, я давно мечтал уйти из Битрикса, но возможность реализовать себя в новом качестве и хорошая зарплата не оставляли мне шанса отказаться.
Забавный факт: единственным условием моего приема на работу было то, что я мог сам выбрать стек технологий, но ни при каких обстоятельствах я не должен отказываться от Битрикса, если на этом настаивает клиент.
В новом месте
На новом месте оказался очень хороший технический начальник, плохой менеджер, младший, мидл и несколько действительно больших проектов на Битриксе.Это довольно странная ситуация и я до сих пор не понимаю, как она сложилась и не развалилась сразу.
Но, возможно, меня пригласили просто для того, чтобы исправить ситуацию.
В первые же дни мне бросилось в глаза множество «детских» проблем:
- информация о проектах хранилась в головах одного-двух человек и больше нигде.
Инструкций и документации тоже не было, и чтобы узнать, как работает тот или иной функционал, нам приходилось пытать того, кто его сделал, если мы его вообще создавали.
- Кажется, не было никаких устоявшихся систем или процессов; все делалось «как-то», «по привычке».
Отсюда суета, неразбериха, срывы сроков, напряжение.
- задачи были поставлены в словах.
Трекеры содержали только названия задач, просто чтобы можно было куда-то записывать свое время (нужно было вводить 40 часов в неделю)
- Сама разработка тоже была не ахти:
- где-то что-то разрабатывалось даже за пределами Git
- где-то программисты по очереди редактировали файлы на одном сервере
- где-то были испытательные полигоны, а где-то нет (но в любом случае они особо не помогали)
- Кроме того, повсюду было очень много дерьмового кода.
Предвидя комментарии, сам Битрикс, к сожалению, тут ни при чем.
- Все общение происходило по скайпу.
Но у меня к нему просто личная неприязнь
Это меня даже в какой-то степени порадовало, так как я могу влиять на показатели уже с первых месяцев.
Их действительно еще не посчитали, но из-за Парето это пока не имеет значения.
К моему разочарованию, в первые месяцы процессы шли довольно медленно.
Во-первых, мне самому приходилось работать по 8 часов в день над клиентскими задачами как программисту, так как рук просто не хватало.
Во-вторых, в условиях такого дефицита времени было довольно опасно вносить большие изменения, которые могли привести к путанице и потере кода или времени.
Теперь перейдем непосредственно к статье и решению задач.
Первым шагом в новой компании было как-то сориентироваться.
Вытягивание информации из голов сотрудников
Когда я приехал, я вообще ничего не знал ни о проектах, ни о клиентах, и эта информация не сохранялась.нигде в текстовом виде.
Поэтому в первую очередь я начал вытягивать информацию из голов коллег в тексты.
По сути, в девелоперской компании есть 2 больших подмножества важных и/или полезных текстов:
- инструкции, регламенты, статьи, функциональные описания, пользовательские истории,.
- Задачи с названием, описанием, комментариями, журналами времени, подписями коммитов, комментариями в коде, автотестами,.
Но поскольку поначалу у меня был еще совершенно неосведомленный взгляд и мне приходилось изучать проекты, видя их впервые, я просто начал переводить свои исследования в текст, создавая тем самым инструкции и описания функционала.
Еще повезло, что в это же время компания начала активно переходить на Scrum (просто совпадение), изменилось рабочее ПО (тоже совпадение), и соответственно бизнес-процессы были созданы с нуля.
И почему-то изначально я имел большой авторитет в глазах коллег.
Поэтому я просто начал сам писать регламенты (в пределах своей компетенции) и переучивать по ним ребят, то есть, по сути, просто диктовать правила и быть примером их выполнения.
Решение проблемы с постановкой и сопровождением задач затянулось более чем на месяц.
Это оказалось узким местом, и в последующих главах я не раз подниму эту тему.
Когда я приступил к работе, руководитель ужасно поставил задачи.
Пример: название задачи «Исправить ошибку на сайте» и всё: ни описания, ни скриншотов, только название и ссылка на проект. Были, конечно, попытки донести до руководителя принципы SMART и важность описания задач, но все усилия срывались на «нет времени описывать задачи».
Одно время я пытался взять на себя часть ответственности за постановку задач, но иронично, что и на это у меня не хватало времени, так как я почти все время писал код. Но сопутствующую проблему получения текущего статуса задач в произвольный момент времени мы решили окольным путем, через координационные звонки и планы на день.
Пополнение штата, интеграция в команду
Практически с самого начала было понятно, что людей катастрофически не хватает (я сам писал код полный рабочий день, но мы все равно не успевали).Решили в первую очередь взять фронтенд, так как оба прогера в компании были бекендами (а я себя тоже больше идентифицировал с бэкендом), и задач хватало, особенно по верстке, да и задач на React и Vue начал маячить на горизонте.
Очень повезло, что у меня был (и есть) друг с фронта, который в это же время стал подумывать об уходе из фриланса, поэтому мы смогли быстро закрыть вакансию, а я получил премию за привлечение сотрудника( еще один плюс руководству, не раньше видел бонусы от персонала).
Практически сразу после переда нашлось 2 задних.
И где-то в это же время ушел Джун (код которого бесил меня несколько месяцев после его ухода).
Итого в разработке сложилась следующая ситуация:
- один «старик»
- я
- трое абсолютных новичков
- работа еще не налажена
- некоторые знания уже утеряны
В основном это были вопросы о жизненном цикле кода (где писать код, как его показывать, куда потом отправить, как собрать релиз), управлении задачами (как брать задачи в работу, как показывать статус, как определять приоритеты) и работе с Git. Плюс ребята еще пытались задавать вопросы: «Как работает АЭ», «Есть ли у нас на сайте БЭ», но почти все в тот момент сводилось только к необходимости изучения кода.
Первым шагом было дать программистам возможность работать и писать код самостоятельно.
Я вел с ними ознакомительные беседы, отвечая на их вопросы, потом, конечно, решил обобщить все вопросы и схемы в статью, которая потом переросла в лекцию, а затем и в совершенно новую схему работы в компании, которая Я расскажу об этом в следующей главе.
Здесь стоит сказать несколько слов о процессе подбора персонала в нашей компании, которая работает до сих пор.
Процесс найма
Во-первых, у нас есть бонус за направление сотрудника, что является довольно хорошей практикой.Во-вторых, мы решили не устраивать экзамен на собеседовании, а дать очень объёмное задание, близкое к нашему повседневному.
Это удобно, поскольку время, затрачиваемое на прием на работу, сводится только к поиску подходящих резюме и легкому собеседованию с соискателями для проверки на адекватность и разговору о тестовом задании, ну и, конечно же, непосредственно проверке задания.
Реально проблему может решить юниор за пару вечеров; Что делает его объемным, так это большая свобода в реализации, улучшениях и хитростях, которые напрашиваются сами собой.
Именно такая гибкость реализации помогает нам оценить уровень соискателя.
Сразу говорим, что для нас самое главное — уложиться в срок решения задачи (названный самим исполнителем) и в конце показать рабочий код в репозитории.
Мы не оговариваем использование каких-либо подходов и технологий, их выбирает сам исполнитель, но для того, чтобы пойти на встречу и дать советы, мы перечислили возможные улучшения списком, как задачи со звездочкой, например, работа через Ajax, доп.
внутренняя проверка, защита от спама, разработка модуля, использование D7, .
Общий:
- О характере человека можно судить по резюме и собеседованиям.
- Исходя из сроков выполнения задачи, того, что код работает и использования git, мы принимаем само решение о найме.
- Исходя из качества работы, мы определяем уровень и соответственно зарплату, которую можем предложить.
- плюс уже на тестовом задании мы показываем, какие задачи придется решать на новом месте
Настройка системы разработки и доставки кода
На тот момент у нас было несколько проектов, которые развивались достаточно хаотично:- где-то был мастер на бою, где-то другая ветка
- В некоторых местах были испытательные полигоны, в некоторых — нет.
- а если и были, то адреса у всех были разные
- git в основном использовался слабо и скрипя
- изменения в базу данных вносились вручную
- …
Например, я удалил папку битрикс из-под git и переименовал основную ветку обратно в master. Но когда прибыло крупное подкрепление, ситуация стала критической.
Мне приходилось многое объяснять, напоминать людям и писать нелогичные инструкции, поскольку текущая структура разработки была совершенно не интуитивной.
Я не поклонник инструкций как таковых; Я считаю, что их наличие само по себе является индикатором проблемы, поэтому было решено создать общую для всех проектов систему, в которой нужно разобраться один раз и которая самой своей структурой устраняет многие проблемы и вопросы.
Система выглядит следующим образом:
- У каждого разработчика есть удаленное личное рабочее место, где он работает.
- есть платформа, где аккумулируется функционал для следующего релиза
- при необходимости имеется демонстрационная площадка для демонстрации всех азов функционала
- весь код одной задачи хранится в одной отдельной ветке, где имя ветки равно названию задачи в трекере
- чтобы загрузить код на общую платформу, нужно просто слить куда-нибудь ветку и запихнуть ее
- изменения в базах данных сохраняются в виде файлов миграции в ветке задач.
Процесс переноса всех проектов в эту систему, конечно, занял много времени (например, на одном проекте нам загадочным образом не удалось перенести на мастер с первого раза), и он продолжается до сих пор, но в итоге мы получили по меньшей мере:
- возможность выпускать только необходимые задачи, а не выпускать недоделанный функционал вместе с полезным кодом
- выпустить задачу без привлечения автора кода
- распараллелить работу над проектом между исполнителями
- не потеряй код
- тестировать функционал изолированно от других и не мешать работе прогера
Плюс теперь нет необходимости объяснять ненужные тонкости работы с git или тестовыми сайтами новым программистам, поскольку все универсально и интуитивно понятно.
Скрам, коммуникации, регламенты
Конечно, в статье я намеревался рассказать о том, как я помогал в развитии компании в качестве тимлида, но нельзя говорить о развитии нашей компании, не упомянув нашего начальника и его инициативу, иначе это будет не совсем честно..
Во-первых, он ввел scrum и на момент моего прихода процессы в компании начали очень активно перестраиваться.
Также в этот момент я перевел ее с Битрикс24 на Jira. Скрам определенно привнес в компанию больше ритма и уменьшил хаос.
Переподготовку менеджеров, выполнение ими координационных звонков, открытие/закрытие/планирование спринтов контролировал сам начальник, как старший в этом звене.
Также он много работал над самими менеджерами, особенно над тем, как они общаются с клиентами и программистами, поскольку большая часть их работы (но, конечно, не ограничивается этим) — общение: изолировать программистов от клиентов, переводить клиентов.
' пожелания в задачи в бэклоге и в спринтах, находить и пересказывать пользовательские истории.
Все это вылилось в множество регламентов: по общению с клиентами, по постановке задач, по работе с бэклогом, по приему ошибок.
Особое внимание уделялось коммуникации, и управление действительно продемонстрировало прогресс.
Сам переход на Scrum, конечно, очень сложен и на момент написания статьи мы еще не стали Scrum-профессионалами, хотя все к этому движется.
И я очень рад, что получил много новых знаний по гибким методологиям и продуктам Atlassian.
Новый менеджер.
Тексты, постановка задач, бэклог В какой-то момент пришел еще один человек, который должен был помочь нам совершить качественный скачок – новый менеджер (до этого он у нас был).
Я не ожидал этого момента, так как проектов и программистов у нас было не так много и по идее должно было хватить только одного менеджера.
Это звено было слабым местом в компании, но мы постарались решить эту проблему за счет развития имеющегося персонала.
Так уж получилось, что один отличный менеджер, которого я хорошо знаю, решил сменить работу, об этом узнала моя начальница, так как у нее вдруг было собеседование с нашими подрядчиками и я упомянул об этом забавном происшествии, и мы позвали ее к себе.
Еще один приз) Новый менеджер поначалу повторила часть моего пути, так как столкнулась с теми же проблемами (ничего не знает и негде читать) и начала все заново, но с той разницей, что не трогала код, инфраструктуру разработки.
и прогерскими навыками, но работал с постановкой задач, общением с клиентами, чисткой бэклога, а также старательно вытягивал информацию из головы старого менеджера.
В частности, первое, что я сделал, — это вытащил список контактов клиентов и подрядчиков.
Команда с ней уже была знакома, так как однажды мы пригласили ее в качестве лектора, чтобы рассказать нам о контроле времени.
Плюс задачи стали ставиться более детально, она не добавляла негатива и не переносила его с клиента, статусы задач стали более актуальными в любой момент времени.
Поэтому мы сразу возложили на нее большие надежды.
За первые недели он и его начальник навели порядок в бэклоге одного проекта, в частности, нашли эпопею, просроченную на 2 месяца и еще не начавшуюся.
Кроме того, в принципе появилось много задач, которые нужно было сделать еще месяц назад. Хорошо, конечно, что отставание расчистили, но сделали это слишком поздно.
Сама она очень устала от бардака и не раз пыталась уйти, но мы как-то сильно повысили управленческий уровень.
Задачи стали реже теряться в бэклоге, и программисты стали реже задавать вопросы.
Мораль этой истории будет в конце.
Кризис
Почти через полгода после начала работы мне понадобилось уйти в отпуск.Кстати, об отпуске я договорилась еще при устройстве на работу, так как он планировался как свадебное путешествие, поэтому период моего отсутствия был известен гораздо заранее.
Но я все равно, конечно, нервничал до самого конца, потому что мы только недавно перестали работать «крайне».
За неделю до отпуска я закончил делегировать обязанности, обучил выбранных людей делать конкретные вещи вне кода, назначил каждому программисту ответственность за конкретный проект и завершил или делегировал все свои текущие задачи (тогда я все еще программировал большую часть дня).
).
В середине июля не было никаких признаков беды.
И в первые дни отпуска тоже не было никаких признаков беды.
И тут случился кризис.
В одном проекте у клиента лопнуло терпение, потому что его ожидания по выполнению задач (сроки, список, приоритеты) не соответствовали задаче.
Мы сами это заметили не так давно, когда полностью переработали бэклог и активно общались с клиентом (глава про нового менеджера), но было уже поздно.
А по второму проекту мы наконец приняли очень большую и долгожданную задачу, завершили тестирование и выпустили ее.
Но новый функционал неожиданно обрушил производственную площадку под непосильную нагрузку, и мидл и фронт неделю ничего не могли с этим поделать.
Естественно, этот клиент тоже начал ругаться и подумывать об отказе от наших услуг.
Первая проблема не имела прямого отношения к разработке, поэтому я активно участвовал в исправлении ситуации на втором проекте.
Хотя существенно помочь я не смог, так как находился в другой стране без интернета и ноутбука.
Максимум моя помощь заключалась в консультировании прогеров, особенно когда я уже купил интернет. Бэк, ответственный за проект, работал целую неделю каждый день, пытаясь внедрить новый функционал в производственную среду и вместе с фронтом разбирался в кодовой базе Vue, где большая часть кода была написана не ими двумя ( я, кстати).
Коллега попал в ужасную ситуацию - всю неделю работал до часу ночи, был в сильном стрессе, но в итоге вся вина легла на него, особенно из-за того, что все это время он повторял «Я исправлю».
это к обеду / к концу дня / к ночи / к утру».
В конце концов ситуацию смогли исправить, но все это привело к тому, что пока мы решали его дальнейшую судьбу, он сам написал заявление об увольнении, так как устал от такого стресса.
Самое странное, что, судя по общению с ребятами, все это время они действительно работали, и даже быстро нашли проблемное место, но на его решение ушло много десятков часов и потом столько же времени на исправление поломок.
появившегося мелкого функционала.
Мы много думали о том, почему произошла такая ситуация и как предотвратить ее в будущем.
Явно выявился недостаток профессиональных навыков и умения оценивать задачи, поэтому для профилактики мы решили ввести добровольно-принудительный набор программистов внутри компании.
На необходимость этого также намекало наблюдение, что у прогеров с сторонними проектами подобных проблем не возникало.
Разработка программиста
Критически важно было повысить квалификацию программистов.Застой - это в принципе маленькая смерть (и один реальный прецедент увольнения уже есть), к тому же уже начали появляться проблемы из-за недостаточности знаний или навыков:
- технический долг накапливался
- ребята часто жаловались на проблемы с git
- исправление неожиданных ошибок заняло много времени
- новые технологии внедрялись очень сложно
- знакомство с чужим кодом было прямым препятствием
Поэтому возникла необходимость централизованно развивать программистов внутри компании.
Обзор кода
Я старался чаще просматривать код, но этого было недостаточно.Ребята, конечно, читали мои комментарии, но комментарии повторялись снова и снова.
Лекции
Другая идея заключалась в проведении лекций.Например, я однажды собрал все примеры хренового кода, которые нашел во время code review, в один большой файл с пояснениями для каждого случая и рассказал о них по телефону.
Такое прямое указание было, конечно, полезнее.
Кстати, именно в формате лекции я учил ребят работать с Vue, которым мы потом очень часто пользовались.
В общей сложности лекций мы прочитали не так много, где-то около 5. Во-первых, никто из других программистов не подготовил свою лекцию.
И это не решало проблем с хреновым кодом и превышением оценок, но они были самыми главными.
Совместные заседания
Особенно меня расстроила проблема с Git, такого количества я еще никогда не видел: слияния приводили к потере кода, разрешение конфликтов иногда приводило к падению сайта, файлы в коммитах иногда помечались как полностью переписанные, и в принципе коммиты и сообщения для них были совершенно неинформативны.Я думал, что это связано с тем, что ребята работают с git через консоль или еще как-то.
Это привело к идее не просто звонить друг другу и читать лекции, а звонить друг другу и вместе писать код, показывать, как работать в Storm, как делать коммиты, как разрешать конфликты через удобный интерфейс, как проводить рефакторинг.
код и между ними и просто обсуждать все виды программирования.
И этот формат сработал.
Мы стараемся встречаться каждую пятницу.
Показываем друг другу всякие штучки в Storm, куда наконец-то переехала вся команда благодаря звонкам, избавляемся от вопросов по git, улучшаем качество самой разработки.
Плюс я считаю, что такие еженедельные звонки по программированию поднимают дух программистов, так как мы не просто разбираемся, почему пришла неправильная цена от 1с или добавляем на сайт очередной раздел с акциями, а как-то развиваемся, тесно общаемся без менеджеров и клиентов.
рядом, каждый делится немного своим опытом и тем, что его интересует, разбираем возникшие технические проблемы, подтягиваем тех, кто отстает. И я не только у них ведущий, наоборот, довольно часто я даю инициативу и ребята сами начинают транслировать полезные вещи.
Экомандная эффективность, оценка задач
Одной из самых больших проблем в компании было постоянное превышение сроков выполнения задач.Иногда среднечасовое превышение в месяц достигало двух раз.
Особенно остро проблема обострилась во время моего отпуска, когда целую неделю задание с самого начала переносилось на несколько часов вперед, то есть каждые 3-4 часа говорилось «нужно еще 3 часа», а в в конце потребовалось почти 40. Опять же, благодаря руководству, мы не остались в минусе и никого не уволили, но протягивание задач стоило нам как минимум премий, а как максимум могло привести к потерям.
Соотношение факт/оценка выполнения работы в часах мы прозвали - эффективностью (ну, как они это назвали).
Эффективность всей команды стала моим KPI, как главной задачей тимлида.
Я был рад, что у меня есть числовой KPI. И моя радость еще больше усиливалась тем, что в то же время я наконец перестал программировать по 8 часов каждый день и теперь мог полностью заниматься вопросами руководства командой.
Мы много думали над вопросом эффективности.
Явных утечек не было:
- программисты вполне здраво оценили задачи
- действительно работал над ними, а не просто ставил таймер
- проблем со связью не было
- была ловушка
- окончательное решение не устроило клиента
- некоторые связанные функции отвалились
- во время тестирования что-то упустили, а потом переделали
- потраченное время на поиск доступа
- .
- качество оценки задач, что ребята до сих пор часто просчитывают
- на уровне самого программиста, из-за чего формируются задачи «черной дыры» и исправление ошибок затягивается на часы.
Это также может вызвать путаницу при встрече с неизвестными технологиями.
- дерьмовый код, связность кода.
Хотя эта проблема косвенно пересекается с предыдущей
- при постановке задач, так как часто слышал жалобы на неполную информацию в описании, плюс этот же пункт мог привести к ненужным переделкам
И это принесло несколько новых открытий:
- задачи, первоначально рассчитанные ровно на 1 час, почти всегда превышались
- тестирование задач почти никогда не входило в оценку и зачастую именно оно превышало
- неожиданно и неприятно, но в таймлогах часто упоминались проблемы с git. Причем большие бревна, иногда по полтора часа
- Все оценки и постановку всех новых задач я лично проверяю каждый день, особое внимание уделяя, конечно, мелким задачам.
Так мы боремся с неадекватностью оценки и неполнотой производства.
- переносим всех ребят в шторм, чтобы они хотя бы перестали возиться с мержами в консоли
- Во все задачи мы закладываем время на тестирование, коммуникацию и сдачу клиенту.
- Мы проводим еженедельные созвоны с узким кругом программистов, где вместе программируем, делимся знаниями, хитростями, учимся разрешать конфликты и параллельно рефакторим код.
Например, после второго вызова проблемы с гитом ушли.
Эффективность начала повышаться, хотя и не очень быстро.
На данный момент мы по-прежнему прилагаем много усилий и не прекращаем изучать этот вопрос.
Чему я научился на новой должности
Персонал – самое главное
Вы можете покупать все продукты Atlassian и Jetbrains, говорить умные вещи, вводить кучу регламентов, договариваться с клиентами о схемах постановки задач, но если ваши коллеги саботируют регламенты, работают «по привычке» и не используют новые инструменты, то там нет смысла в инновациях.Также инициативный человек всегда выгодно отличается от просто хорошего сотрудника хотя бы тем, что может выйти из своей «законной» зоны ответственности и не дать задаче застопориться, а может предложить какое-то общее улучшение без просьбы.
сверху.
Личные качества важнее профессиональных
Например, у вас может быть классный специалист, который всегда соблюдает сроки, может решить любую задачу, пишет идеальный код, но он, если Бог даст, 2 часа в день или вдруг берет выходной среди недели.Этот приносит несравнимо больше проблем, чем пользы, особенно когда в его задачах обнаруживаются ошибки.
Или можно представить ситуацию, когда есть два одинаковых сотрудника, но один из них читает профессиональную литературу и/или ведет личные проекты, а второй нет. Изначально они одинаковы по зарплате и навыкам, но через некоторое время второй начинает тянуть компанию вниз и облажаться, а первый все равно продолжает выполнять свои задачи или даже обгонять более опытных коллег.
Моменты, когда люди отказываются брать на себя ответственность, тоже очень вредны.
Это приводит к саботажу заданий или тупиковой остановке заданий в случае отсутствия связи с первоначальным исполнителем и/или необходимости совершить что-то потенциально опасное, например, разрешить конфликт или выполнить какое-либо действие на месте боевых действий.
Ээмоции коллег влияют на многое (больше, чем я думал раньше)
Многие люди не любят свою работу из-за стресса.Стресс может быть вызван, например, уровнем зарплаты, токсичностью коллег, глупостью клиентов, дорогой на работу, рабочими обязанностями и миллионом других причин.
Клиенты, непредвиденные обстоятельства и коллеги могут принести новый стресс в работу.
Но вы можете проигнорировать первую, решить вторую, но вы каждый день будете видеть вечно ноющих и депрессивных коллег.
В общем, чем бы мы ни занимались: писали код, занимались дизайном, работали с бухгалтерией, мы все равно так или иначе работаем с людьми, и именно они больше всего влияют на наше настроение.
И не исключено, что именно общение с коллективом определяет, останется человек в компании или нет.
Нельзя усидеть на двух стульях
Поначалу мне приходилось писать код целыми днями, из-за чего у меня вообще не было времени выполнять свои чисто командные обязанности, я просто помогал команде в целом более-менее укладываться в сроки.Но это все равно, что катать квадратное колесо, когда вас просят его заточить.
Более популярные вредные примеры смешивания обязанностей:
- программисты долго общаются с клиентами и потом не соблюдают сроки
- менеджеры занимаются распределением всех задач между исполнителями, что съедает все их время
- контент-менеджеры пытаются отредактировать код и сломать сайт
- менеджер пытается передать жалобу программиста на код другому программисту
- 1сники пытаются придумать хорошее решение
Планы
Изначально, когда я только начинал задумываться о смене работы, мне хотелось поехать на Кипр, потому что я ждал от него солнца (стереотипы о Питере – вовсе не стереотипы), спокойствия, хорошей зарплаты, интересных задач и отсутствия стресса.Но Москва предложила мне условия, от которых я не смог отказаться (карьерный рост, зарплата в 2 раза больше нынешней, площадка для экспериментов и практически полная свобода действий).
С другой стороны, если задуматься, мы тоже Европа.
Поэтому я хочу «приблизить сюда Кипр», то есть, чтобы команда:
- Меньше стресса на работе
- перестал дико уставать
- избавился от негатива исходящего от коллег и клиентов
- имел возможность гордиться своей работой, то есть перестать исправлять баги и разгребать лажи, а создать что-то крутое
- когда-либо уходил из Битрикса и использовал новые технологии.
- и конечно увеличение прибыли
Часть 2
Эта статья охватывала примерно шесть месяцев моей работы на новой должности.Во второй части хотелось бы рассказать о том, как мы движемся к целям с помощью:
- автотестирование, которое мы только начинаем внедрять.
Странно, но на Битриксе почему-то нет достойных примеров
- избавление от наследования в коде
- дальнейшее ускорение и упрощение разработки
- что я почерпнул из комментариев
- много других пока секретных вещей (а вдруг мои ребята меня прочитают)
Буду очень рад комментариям, особенно если вы знаете более эффективные способы решения проблем, с которыми мы столкнулись.
Всем удачи и радости в работе и жизни! Теги: #Управление проектами #управление командой #лидер команды #развитие компании #карьера программиста #программирование #Управление разработкой #Управление проектами #Управление персоналом #Карьера в IT-индустрии
-
Взломаны 33 Популярных Аккаунта В Твиттере
19 Oct, 24
