В статье я расскажу о моём опыте работы на должности тимлида в компании по разработке сайтов. Чтобы всем было полезнее и проще читать, статья разбита на главы, каждая из которых рассказывает об одной отдельной проблеме и её решению. Хотя по возможности будет сохранена хронология событий.
Надеюсь, что описанный ниже опыт станет для кого-то чужими граблями, а в комментариях я и сам почерпну что-то от более опытных коллег.
Но никаких названий, компаний, клиентов, имён коллег. Договор о неразглашении, все дела.
Предыстория. Как и где я вообще стал тимлидом
Это первая фирма, куда я пришёл сразу тимлидом. Для меня это был качественный скачок в плане карьерного роста. На прошлую работу (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
Эта статья охватила примерно полгода моей работы в новой должности. Во второй части я бы хотел рассказать о том, как мы движемся к целям с помощью:
- автотестирования, которые мы только начинаем внедрять. Странно, но почему-то на Битриксе нет достойных примеров
- избавления от наследства в коде
- дальнейшего ускорения и упрощения разработки
- того что я почерпну из комментариев
- множества других пока секретных вещей (вдруг меня мои ребята читают)
Всем спасибо за прочтение. Буду очень рад комментариям, особенно, если вы знаете более оптимальные пути решения проблем, с которыми мы сталкивались.
Всем удачи и радости в работе и жизни!
Комментарии (152)
Lexicon
16.09.2018 19:28Блин, тоже пишу статью, но скорее про собеседования, коллег и управление, чем про себя.
Я скорее архитектор/тех.дир, нежели разработчик.
В свое время понял, что больше всего меня не устраивало в компании именно руководство и как бы я не любил разработку, как бы не вертелся на пике bleeding-edge и не ценил объективно низкий уровень реальной конкуренции, определенно было ощущение, что занимаюсь чем-то не тем.
Добили собеседования после смены компании, некомпетентность начальства, ведущих разработчиков(именно как руководителей) уже на этом этапе бросается в глаза.
В итоге пришел на проект с ужасающей архитектурой, безопасностью и тратами на разработку, но зато все по методологиям, менеджер мог расписать каждые 10 минут. Стал ведущим разработчиком, затем тех.диром, а потом ушел, но определился со своей ролью на будущее.
Сейчас, для маня главное — прозрачность, стресс порождается ее отсутствием. Например, если предложенные тесты на вакансии проверяют только на стрессоустойчивость(например простые задания, или задания на запоминание википедии), от них выгодней открыто отказаться ( написать, что задач не будет). Любые правила и защита — автоматизируемы, если правило нельзя автоматизировать и нет ответственного лица — оно не служит для защиты, а следовательно — устраняется.
Я искренне ценю мысли, подобные вашим впечатлениям из части "Чему я научился..." и так же искренне желаю вам не предавать эти убеждения и расти, как в разработке, так и руководстве.
Vasek18 Автор
16.09.2018 20:22Спасибо за тёплые слова. Уверенный, что вы хороши в своей деятельности и у вас всё получится!
Я провёл свои первые полгода с уклоном в руководство и каждый месяц очень многому учусь. Больше всего надеюсь, что команда под моим началом будет развиваться, особенно в индивидуальном плане каждый из коллег
afi13
16.09.2018 19:31Используете ли Github, Gitlab, Bitbucket или что-то подобное? Использование pull-реквестов устранило бы проблемы с мержами в команде и облегчило код-ревью.
Vasek18 Автор
16.09.2018 20:27Да, мы работаем через Bitbucket.
В последнее время я тоже думал о переходе разработчиков на пулл-реквесты, может быть проведу эксперимент хотя бы на одном проекте.
Но мы сейчас активно расширяемся, плюс сами ребята быстро растут в профессиональном плане, а также на проектах большое количество подрядчиков (сеошники, 1сники, контент-менеджеры, ..), так что возможно закреплю по человеку на проект и тоже пулл-реквесты.afi13
16.09.2018 21:02Можно выделить немного времени в конце дня и совместно делать код-ревью всех pull-реквестов созданных в течении дня, разбирая проблемы по горячим следам со всей командой. Это позволит сократить совместные сессии, но при этом улучшить качество кода. Плюс неплохо бы прикрутить не только автотесты, но и статические анализаторы(типа sonarqube, phpstan и т.д.) к pull-реквестам, это позволит выловить потенциальные баги еще на этапе ревью.
Vasek18 Автор
16.09.2018 22:09Хм, крутая идея. Нужно будет подумать над
kaljan
17.09.2018 09:53Плюс код ревью помогает шарить знания
Vasek18 Автор
17.09.2018 10:03Я ещё думаю подключить ребят к ревью кода сейчас как-нибудь малой кровью.
Хотя бы ревьюить мой код. Его сейчас никто не смотрит. И ребята пока не ревьюят код коллег. Как раз для передача знаний это чуть ли не основная выгода здесьkaljan
17.09.2018 10:05ну у нас нельзя смержить PR без ревью (а для фронта еще и билд прогоняем)
Работает хорошо — сейчас взяли на поддержку проект от другой команды, из старой команды остался только фронт и бэк. Путем обработки 4-5 ревью разработчики начинают писать одинаковый код, в котором потом можно легче найти баги
Ну и без тестов, естественно, никто никуда не едетkaljan
17.09.2018 10:06+1тесты не раз спасали от потери функционала после конфликтных мержей, т.к. их сложнее криво смержить
Vasek18 Автор
17.09.2018 10:36Думаю, что в идеале код действительно должен ревьюиться через PR. Активно идём к такой схеме
Lissov
19.09.2018 00:27Жирный +1, сам собирался написать.
Pull-реквесты очень сильно повысили качество у нас.
Что используем: TFS + git, основные ветки имеют полиси — мерж только через пулл-реквест, с билдом и привязанными тасками. Билд, понятное дело, с тестами и линтером. Более медленный статический анализ и UI-тесты проходят ночью. Есть формальный чеклист для ревьювера — проверить закрытие задачи, репортинг времени, тесты, документацию — то что пока не смогли автоматизировать. Отключать полиси имеет право только техлид и никогда (почти) этого не делает (это к вопросу о доверии — техлид работает в тех же условиях).
Перед релизом QA команда смотрит список фактически попавших в билд задач (вот это очень хорошо сыграло, перестали пропускать недоделки и забытые вещи). И проверяет что ночной билд зеленый. Даже если не зеленый, всегда понятно можно ли релизить.
ИМХО есть огромная разница между «иногда я делаю код-ревью» и «каждая строчка кода обязательно проходит ревью». За один день ревью перестает восприниматься как придирка и становится частью процесса.
postback
16.09.2018 20:00+2два одинаковых работника, но один из них читает профессиональную литературу и/или ведёт личные проекты, а второй нет.
Вы действительно считаете что после того как человек проработал 8 часов за день, потратил еще 2 часа на дорогу приедет домой и у него будет здоровое желание повести личный проект?Vasek18 Автор
16.09.2018 20:36Не считаю и не от кого не требую. Упомянул личные проекты, т. к. заметил корреляцию между наличием личных проектов и прогрессом в профессиональном плане.
И, кстати, с этими мыслями мы ввели добровольно-принудительное обучение в рабочие, оплачиваемые часы.
Но к оправданию людей с проектами, у нас таких как минимум двое (Мы не поднимаем этот вопрос из-за этических соображений). У одного проекты на Андроиде, у другого на Ларавеле. Так что это как хобби получается.cyberly
16.09.2018 22:22+1>> заметил корреляцию между наличием личных проектов и прогрессом в профессиональном плане.
В общем-то, логично… Наличие личных проектов может говорить о том, что у человека нет личных/домашних проблем, которые жрут время и нервы, а также о том, что состояние выгорания ему в данный момент не угрожает. Плюс, сторонние проекты в смежных областях могут быть неплохим источником свежих идей.Vasek18 Автор
16.09.2018 22:53Кстати, да. Эти же ребята ещё и самые спокойные и стрессоустойчивые
Я, вообще, думал, что причина в свежих идеях, потому что один парень вырос за несколько месяцев с миддла до сеньора по моему имхо и один из немногих, кто использует ООП вне взаимодействия с D7Sowd
17.09.2018 13:16Расскажите, как вы разделяете мидла и сеньера? Мой коллега пришел пару месяцев назад на позицию джуна, и с первых дней пользует в модулях и компонентах новомодные битриксовые тренды, д7 и орм. Но ведь сеньором его из за этого назвать нельзя? Или можно?
Vasek18 Автор
17.09.2018 13:21Это очень, очень субъективно. Я использую наверное 20 или 30 пунктов часть из которых вообще из soft skills.
Кстати, опыт показал, что миддл может использовать D7 очень хорошо. Проблема как раз в том, что чтобы писать на Битриксе на 5+ не нужно быть очень крутым программистом из-за компонентного подхода и любви Битрикса к «портянкам» кода. Да и D7 плохо продокументирован и не все решения в нём мне нравятся.
В вашем случае, если человек будет хорошо писать код, отвлечённый от D7, с нуля, например, что-нибудь связанной с апи от/для стороннего сервиса, то он уже не джун.
Но опять же, у меня занимает сколько-то недель код-ревью и общения, чтобы понять уровень разработчика
mihacoder
17.09.2018 10:03Я нахожу два-три раза в неделю время на свои проекты или на изучение чего-то нового. Ибо то, что нравится, не требует больших волевых усилий. А вот подработки по вечерам прекратил, потому что начал ненавидеть и их, и основную работу.
Vasek18 Автор
17.09.2018 10:08Подработки я совсем не одобряю.
Они реально забирают ментальные силы и желание работать. Особенно, если у тебя есть жена/дети/девушка/друзья/..., которые вечером ждут твоего внимания.
Единственный способ борьбы с ними повышение ЗП до некоего уровня, когда человеку будет хватать на всё.
Я рад, что вам нравится ваша сфера и вы готовы делать чуть больше в ней, чем требуется работой
0xd34df00d
18.09.2018 21:41Да, вполне. Если я делаю то, что мне нравится. Ну, это как резьба по дереву, или игра в танчики, или ещё что-то. Только программирование.
Впрочем, да, скажем, полноценно ботать какой-нибудь матан у меня по вечерам получается не всегда.Vasek18 Автор
18.09.2018 23:52У меня жена жаворонок и переманивает меня в свою секту, так что теперь я нахожу 20 минут перед работой.
Плюс этого в том, что тебя хватает на сложные0xd34df00d
19.09.2018 07:41Ну, делать что-то заходами по 20 минут лично у меня не получилось бы.
Vasek18 Автор
19.09.2018 18:30Этот способ называется редукционизм. Так хотя бы в контексте остаёшься и тратишь времени больше нуля.
По крайней мере я себя этим успокаиваю)
vanxant
16.09.2018 22:07Статья отличная, пишите еще!
Также подкину идейку: статья про мерджи бд в гите для битрикса отлично бы зашла.Vasek18 Автор
16.09.2018 22:48Мерджи бд? Вы наверное имели ввиду миграции?
Для миграций, кстати, мы используем просто один бесплатный модуль с Маркетплейса. Там каждая миграция хранится в отдельном классе-файле с таймстемпом и есть удобный интерфейс по запуску их через
edwardspec
16.09.2018 23:10+4Ответственный за проект бэк [...] разбирался в кодовой базе vue, где большую часть писали не они двое (я как раз, кстати). [...] попал в ужасную ситуацию — работал до часу ночи всю неделю, сильно стрессовал, но и на него же по итогу свесились все шишки, в особенности из-за того, что он всё это время повторял “починю к обеду / к концу дня / к ночи / к утру”. [...] всё это вылилось в то, что пока мы решали его дальнейшую судьбу, он сам написал заявление об увольнении, так как устал такого стресса.
Хочется надеяться, что фраза «решали дальнейшую судьбу» означает «решали, сколькократную премию ему дать за усердную и сверхурочную работу», а не «решали, не уволить ли чувака, который из кожи вон лез спасти всех от бага, который внёс не он».Vasek18 Автор
17.09.2018 10:11К сожалению, про премию не было и речи.
Парень действительно был отличным: ответственный, позитивный, трудолюбивый, но тут личные качества не спасали, так как образование таких «чёрных дыр» у него было слишком частой практикой.
Звучали разные идеи. Самыми приятными и безобидными были идеи вроде «сидеть с ним вдвоём и вместе оценивать задачи, которые он собирается делать, потому как проблема возможно отчасти в оценке»
Lissov
19.09.2018 00:42+1Видел уже такую ситуацию, к сожалению это типично оканчивается увольнением, причём именно что и «сам работник с радостью ушёл». Интересно, что сам один раз так попал, и тогда как раз менеджмент спас ситуацию без увольнения меня :)
Выработал для себя пару правил, которые надеюсь могут помочь. Во-первых надо вовремя распознать, что человек закопался. Предложить пересмотреть сроки, подвинуть дедлайн. Во-вторых просто пропускать мимо ушей «починю через час» — это всё равно не правда, ясно ведь. Далее если не помогло — срочно передать всю задачу целиком другому. Это сложно, ведь этот может оказаться самым знающим, тогда хотя-бы подключить второе мнение. Лид или менеджер должен взять на себя всю ответственность за провал и перенести сроки. Больно и не хочется, но надо. И только после успешного релиза обсудить «что пошло не так и как сделать лучше в следующий раз». Но сначала признать, что человек таки сделал хорошую работу, в общем то.
А далее уже параллельно думать, нужен ли он в команде. Понимать, что с точки зрения морали команды, повесить всех собать и дать уволится — плохое решение.
Опять же, доводилось работать с людьми, у которых были проблемы с оценкой, с коммуникацией оценки, вообще с тем чтобы сказать «нет». В некоторых случаях (не всегда, конечно), лучше всего просто учитывать и подстраиваться самому.
maydjin
16.09.2018 23:43+1Придя с галеры, в дикие прерии, он одолел дракона, показав как стучать на барабане.
lxsmkv
17.09.2018 00:13На момент начала моей работы менеджер ставила задачи ужасно. Пример: название задачи — “Исправить баг на сайте” и всё: ни какого-либо описания, ни скринов, только название и отсылка к проекту. Были конечно попытки донести принципы SMART и важность описания задач до менеджера, но все начинания разбивались об “У меня нет времени расписывать задачи”.
У нас похожая история.
Я тестировщик. Недавно я написал нашим тимлидам, что давайте введем критерии качества для тикетов и задач. Их элементарным качеством должна быть проверяемость. Т.е. если это баг- разработчик должен иметь возможность воспроизвести сценарий самым простым способом. (Я это называю «дай шанс разработчику пофиксить проблему») Если это задача, то она должна быть расписана так, чтобы третье лицо могло убедиться в том что она выполнена. Так же и разработчик, после обработки задачи, должен занести в тикет всю информацию необходимую для тестировщика или любого третьего лица, чтобы убедиться в том, что задача была действительно выполнена или проблема была исправлена.
Все отговорки — банальное проявление или попытка проявления халатности. А халатность в работе заводит в конце концов в Петлю Страха
Это не так трудно как кажется. Я когда пишу тикет, даю полный расклад, потому что хочу чтобы задачу быстро решили. А потом, проверяя исполнение, я не хочу мучительно вспоминать как воспроизводится эта проблема. А цикл от создания тикета до его решения бывает и пару месяцев, и тогда ты уже точно можешь не надятся на свою память. И это окупается. Редкие случаи когда разрабам приходится подходить и что-то переспрашивать. И даже в таких случаях все сводится к тому, что я открываю тикет в багтрекере и просто зачитываю из него с параллельной демонстрацией на продукте. Ну поленились прочитать. Бывает.
Когда я завожу технический баг, например на наш тестовый фреймворк, то прилагаю файл с тестом с помощью которого можно проявить проблему. Так же, если я хочу какую-то фичу в тестовом фреймворке, то к текстовому описанию с указанием моего намерения (зачем, для какого сценария мне это надо) прилагаю файл с тестом, в котором показано, как я хочу это использовать. Задача исполняющего — сделать так чтобы это заработало. Такие таски выполняются на удивление быстро и с минимумом доработок.
Короче: чем хуже описание — тем дольше будет обрабатываться. Причем не в масштабе «час-два» а в масштабе «день-неделя». Это связано с устройством работы мозга. Все что непонятно он с удовольствием откладывает на потом.Vasek18 Автор
17.09.2018 10:15Описания задач крайне важны, вы правы.
Я рад, что у нас уровень постановки сильно повысился. Но странно, что не все считают это критически важным даже с несколькими годами опыта.Lissov
19.09.2018 00:49А это уже Ваша работа. Вон там человек написал:
Все что непонятно он с удовольствием откладывает на потом.
И это неправильно. Девелопер не имеет права отложить баг на потом. Зато может с поддержки техлида просто вернуть назад тестировщику с пометкой «непонятно». В клинических случаях когда название задачи «исправить баг на сайте» — ответ должен быть аналогично идиотским, вроде "исправил баг на сайте", либо "открыл сайт, он открылся. Значит бага нет.".
А потом ведь менеджер может и спросить, как это у нас в проекте 10 критических багов и все тестерам вернули.ApeCoder
19.09.2018 09:50ответ должен быть аналогично идиотским, вроде "исправил баг на сайте", либо "открыл сайт, он открылся. Значит бага нет.".
Я думаю, для дела будет лучше написать, "не удалось воспроизвести, недостаточно информации" и привести ссылку на принятые рекомендации по оформлению ошибок типа https://geteasyqa.com/qa/write-bug-report/, но адаптированную для вашего продукта.
tcapb1
19.09.2018 18:16Наверное это правильная стратегия, но не все в силу характера будут перечить. Кто-то будет старательно вчитываться, пытаться понять, не понимать, и уже уставшим переключаться на что-то более понятное.
Плюс чёткое описание задачи и разбиение на подзадачи помогает более адекватно оценивать время на её решение. При общем описании много нюансов можно просто не увидеть.
Quilin
17.09.2018 17:34В своем петпроекте в разделе форума "ошибки" я ввёл и описал подобные правила заведения багрепортов. Обычные юзеры, многие далёкие от разработки или тестирования стали ВСЕГДА писать нормальные описания ошибок. Я не представляю как люди за зарплату могут этого не делать. Похоже на саботаж, мне кажется.
eugene_bb
17.09.2018 19:02У нас в конце концов помогло то что было введено правило, что тикеты создаются клонированием одного из типов шаблона, т.е. для бага один шаблон, для истории другой и т.п.
Шаблон содержит несколько параграфов и текст который нужно заменить ( в примере всё что выделено italic).
Получается что пользователя мотивируют правильно создать тикет.
Пример части шаблона для дефектаExpected behavior
Describe behavior that is expected
Actual behavior
Describe what is actually happening
Steps to reproduce
Provide detailed steps to reproduce the error and any additional conditions (if any)
Environment
DEV / QA / PROD
User name and role
Provide a user name and role (regular user/admin/moderator)
Date/time of the error happened
To be able identify the error in logs, we need to know exact date/time when error happened
и т.д.
Vasek18 Автор
17.09.2018 21:29-1Я довольно предвзято отношусь к надписям на английском, хотя встречаю их только в коммитах, не в задачах. Даже те, кто знают язык, сильно сокращают тексты.
Шаблоны это хорошо. Они наталкивают на идеи и экономят ментальные силыeugene_bb
17.09.2018 22:10+1Ну я один русскоговорящий в команде, так что хочешь не хочешь, приходится пользоваться.
lxsmkv
17.09.2018 23:19Шаблон по сути не решает. От просто придает структуру.
Вот описание случайно выбранного бага на файрфокс
ОписаниеUser Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180607193927
Steps to reproduce:
* Open a new tab
* Paste an address in.
* Press enter.
Actual results:
* Spinner appears in tab.
* No content ever loads in page (blank page).
* Spinner never stops or times out.
* Right-clicking window no menu appears.
This happens about 10% of the time.
Happens on 3 different networks (two separate WiFi networks at separate locations and via tethered phone network).
Loading the same URL via Curl instantly returns (see attached gif).
Disabled all add-ons, still happens.
Disabled «Use hardware acceleration when available», still happens.
Expected results:
* Page should load.
Version 60.0.2 (64-bit)
Ubuntu 14.04.5 LTSeugene_bb
17.09.2018 23:59Я написал про собственный опыт. У нас пользователи не заводят непонятные тикеты, но без использования шаблона структура тикета становится «как-бог-послал». Т.е. некоторые секции пропущены, в других информация не та что ожидалась и т.п. А шаблон ведёт мотивированного пользователя по правильной дороге.
По прошествии пары лет, результат от использования шаблонов — строго положителен.lxsmkv
18.09.2018 00:58результат от использования шаблонов — строго положителен.
это однозначно так. Причем я заметил, что хорошие практики ведения тикетов иногда приживаются и перенимаются другими тестировщиками. Например я первой строчкой пишу на какой конкретно сборке был сделан тест (одна версия у нас содержит множество сборок, под разные платформы, языки и пр. ) Это сразу отсекает множество вопросов при воспроизведении, и говорит, «я проводил тест только на этом билде и ни на каком другом.»
У нас используют в шаблоне A(ction), O(bservation), E(xpectation) выглядит это примерно
такA1:…
A2:…
O2:…
A3:…
O3:…
E3:…ApeCoder
18.09.2018 08:27Например я первой строчкой пишу на какой конкретно сборке был сделан тест (одна версия у нас содержит множество сборок, под разные платформы, языки и пр. )
А нельзя это делать не шаблонами, а обязательными полями в багтрекере?
tcapb1
19.09.2018 18:27Здесь скорее проблема в сложновоспроизоводимости самого бага. В 90% случаев такие описания очень помогают, так как по сути содержат в себе мини-инструкцию: сразу понятно куда копать.
Плюс даже если баг воспроизводится только на одном компьютере- не факт что такие условия сложатся только у него. Вот из моего опыта за последние пару недель:
— У одного клиента не проходили запрос на сайт, так как в url содержалось слово advertise, и такие запросы резал Adblock. Без Adblock не воспроизводилось.
— У другого был заблокирован один и CDN, с которого сайт подтягивал скрипты
— у третьего в один момент роутер стал резать http-запросы, которые были длиннее X байт (такие клиенты по сайту ползали нормально, однако отправка больших форм не проходила).
А у меня сайт, я вообще к инфраструктуре клиента не имею никакого отношения.
Это же не значит, что такие задачи надо откладывать.Vasek18 Автор
19.09.2018 18:35Как вы вообще находили проблемы в таких нетривиальных случаях?
Особенно третий
Первые два ещё можно через удалённый доступ быстро распознать
Lissov
19.09.2018 00:52+1С другой стороны, логично написать что воспроизводится редко и потому приоритет низкий.
На последней неделе был случай, когда нашёл странное место в коде, и смутно вспомнил что видел баг. Перепроверил, исправил, все довольны. Если бы бага не было — мог бы подумать что так и надо.
Срабатывает редко, но бывает. А вообще должен быть критерий, какие баги надо сразу править, а какие можно отложить пока не всплывут.
Vasek18 Автор
17.09.2018 19:26Да, мне тоже было непонятно это. Тем более, что у человека, который хуже всех ставил задачи, что-то около 20 лет опыта в IT. Хотя возможно это и есть причина
humbug
17.09.2018 01:19"У меня нет времени расписывать задачи"
А чем он[a] занимался?
Vasek18 Автор
17.09.2018 10:17+1Много чем, она всегда была занята. Начинала с 10 утра и работала до глубоко вечера, часто даже поесть в течение дня не успевала. Я не сильно разбирался, почему она постоянно «в мыле», но это точно вопрос личной эффективности, а не непосильной загрузки
emacsway
17.09.2018 01:21Мы сразу говорим, что самое главное для нас это лишь уложиться в сроки решения задачи (называет сам исполнитель) и в конце показать рабочий код в репозитории.
Тут вы немного нарушаете роль оценки и планирования в Agile. И раз уж Вы решили внедрить Scrum — одну из Agile методологий, то разобраться с ее ролью придется. Видеоролик на эту тему от одного из 17 подписантов Agile манифеста https://youtu.be/eisuQefYw_o
Vasek18 Автор
17.09.2018 10:19Немного не понял, как и почему тестовое задание должно быть аджайл. Но спасибо за ролик, видимо мне придётся посмотреть все 47 минут
emacsway
17.09.2018 01:34Одной из самых больших проблем в компании было постоянное превышение сроков по задачам.
Если будет интересно, буквально вчера я изложил наш опыт как мы в разы увеличили темпы разработки.
lxsmkv
17.09.2018 03:14Я, знаете ли, не до конца уверен, что его эффективность была всего лишь результатом применения «четырех принципов». Дело в том, что в истории нет абзаца «и вот мы внедрили эти четыре принципа в команде, и все стали работать так же быстро как он».
Со стороны (для меня) это больше похоже на карго-культ. Вы приписываете особенности наблюдаемым факторам. Упуская из виду те, которые не наблюдаете.
Вот как это звучит:
«У нас был менеджер- лучше я на свете не встречал, так вот, он каждый день чистил зубы три раза, даже на работе, и отжимался по утрам.» А теперь о пользе зарядки и ежедневной гигиены...
Это может быть большим заблуждением. Ведь причина может быть и не (только) в этом.
Когда человек работает сам по себе он всегда эффективнее человека работающего в команде. Ему не надо координировать свои действия, отчитываться, ходить на собрания, планирования — он сидит и фигачит. Пришла задача, сел делать, сделал, взялся за следующую. В принципе даже со стула можно не вставать.
Вот я, например, пишу тесты на четыре команды в общем 30+ разработчиков, и весьма эффективно. Просто потому, что я работаю сам по себе. Я эксперт в своей области. Проблемы в тестах или приложении я определяю как правило навскидку. Могу править тестовые скрипты вслепую (не запуская их на приложении для проверки), потому, что точно знаю как работает их код. Но за рамками моего «княжества» мои «супер способности» пропадают.
Если меня заставить делать еще и какую-то менеджерскую работу, обучать кого-то, делегировать, координировать, вся моя эффективность сразу сойдет на нет. И общая эффективность сойдет на нет. Потому что четыре новичка, которыми управляет сениор, никогда не провернут столько же, сколько сделает сениор сам, без чужой помощи.
И архитектура тестового кода у меня рассчитана на то, чтобы быстро писать новые тесты. Можно было бы там классовые структуры наворотить — пробовал — понял, что это меня только тормозит. Для себя вывел принцип: «Не корми кодом архитектуру, корми кодом приложение». В моем случае тесты. Вот и весь аджайл.Vasek18 Автор
17.09.2018 10:25Это, кстати, одна из причин, почему я написал статью. До этого не управлял людьми и считаю, что делаю это пока не эффективно
И общая эффективность сойдет на нет. Потому что четыре новичка, которыми управляет сениор, никогда не провернут столько же, сколько сделает сениор сам, без чужой помощи.
Это ловушка. Если работать таким составом, то сеньор будет погребён под грудом мелких задач, а новички так и не будут развиваться
emacsway
17.09.2018 12:26Я, знаете ли, не до конца уверен, что его эффективность была всего лишь результатом применения «четырех принципов». Дело в том, что в истории нет абзаца «и вот мы внедрили эти четыре принципа в команде, и все стали работать так же быстро как он».
Хорошее замечание, спасибо, добавил пару строк.
На самом деле, темпы разработки выросли не только у тех, кто работал с ним, но и, по цепной реакции, у тех, кто работал уже с этими, и даже в других компаниях, и так на протяжении уже нескольких лет.
Fantyk
17.09.2018 18:56Прочитал вашу статью, понравилось. Зацепился за другие — также интересно. Но вот чекать ваш блог на новые статьи неудобно. Вы где то еще их публикуете? Или может подскажете инструменты чтобы следить за источниками типа вашего блога?
Vasek18 Автор
17.09.2018 19:56Я рад, что вам понравилось.
Нет, кроме двух статей на Хабре больше ничего нет или 3 года как неактуально.
Третья статья тоже выйдет на Хабре и думаю, что уже только в следующем году.
Вообще насколько я знаю, на Хабре можно подписаться на автора
voicetranslator
17.09.2018 07:48Вы, Vasek18, видмо, весьма гордитесь своим новым назначением, и вас просто таки распирает от необходимости
похвастатьсяподелиться вашим успехом «карабканья по корпоративной лестнице» со всем миром? Правда, похоже, что определенные особенности корпоративной «этики», равно, как и человеческой психологии, вам пока не удалось постигнуть… Искренне надеюсь, что вам не придется писать через месяц-другой статью, «Как я потерял работу после публикации статьи на Хабре»…
White_Scorpion
17.09.2018 09:56+1все начинания разбивались об “У меня нет времени расписывать задачи”
Автоматический reject на "задачи" подобного типа обычно решают ситуацию.
Т.е. конечно, сначала вежливая просьба, потом получение ЧСВ "я слишком занят/а чтобы...", а уже только потом reject, жалоба "обиженного" индивидуума, чьи "очень важные задачи проигнорированы", общение с начальством "обиженного", аргументация проблемы, после чего "обиженный" получает люлей ещё и от начальства и наконец-то исправляется.
Во-вторых, мы решили не устраивать экзамен на собеседовании, а давать очень объёмную задачу, приближенную к нашим повседневным… Задачу на самом деле может решить и джун за пару вечеров,...
ИМХО — плохая практика. Лично для себя принцип отказываться от вакансий, в которых предлагают задачи требующие более 3-4 часов, просто потому что уже несколько раз тратил на подобное несколько вечеров, а результат нулевой.
White_Scorpion
17.09.2018 10:11P.S. Кстати, наличие тестировщиков — тоже ощутимо влияет на результат. Не "тестирующих разработчиков", а профессиональных, системных тестировщиков. Чтобы минимизировать фейлы на 2-3 разрабов должен быть 1 "тестер".
Vasek18 Автор
17.09.2018 10:31Мы, кстати, взяли одного ручного не так давно. Вроде бы отлично справляется и помогает в общем плане
lxsmkv
19.09.2018 00:13Vasek18 можете вкратце рассказать как ваш тестировщик и разработчики работают вместе? Вы даете ему задачи на верификацию фичей? Он участвует в планировании спринта?
Vasek18 Автор
19.09.2018 13:32Пока не участвует
Общаются в основном через задачи в джире. Тестировщик пишет список багов, разработчик повторяет и исправляет. Пишет довольно подробно и понятно
Сейчас он в основном проходит по основным сценариям каждый раз
Vasek18 Автор
17.09.2018 10:301) Да, мы начали хладнокровно ставить задачи на стоп, если их нельзя взять в работу, даже если они очень важные и срочные. Более менее помогло
2) К сожалению, собеседования это лотерея. Но мы не можем позволить себе брать миддлов и сеньоров без тестового.White_Scorpion
17.09.2018 10:432 — Да, лотерея, но надо заранее чётко понимать, что более менее состоявшиеся мидлы (а уж сениоры тем более) могут плюнуть на слишком долгую задачу и делают это в большинстве случаев. Есть много вариантов, как потратить время интереснее.
Vasek18 Автор
17.09.2018 13:10Как тогда без траты времени понять, что соискатель нам подходит, и соискателю подходят условия, компания и должность?
White_Scorpion
17.09.2018 13:34Никак, но надо понимать изменения психологии с ростом умений и навыков. Что, фактически, только джуниоры согласны на long-term задачи — они нарабатывают репутацию и опыт. Уже мидл скорее всего подумает: "А оно мне надо? 2-3 дня корячиться? Да ещё и забесплатно? Ну нафиг", но он хотя бы подумает какое-то время. Сениор же подумает: "Да блин, я уже всё всем доказал — ну их лесом с их задачами".
Вам надо как-то заставить захотеть решать эти задачи. Т.е. заставить желать эту работу даже сениору, но у них уже есть сложившееся мнение об индустрии и они требуют индивидуального подхода.Vasek18 Автор
17.09.2018 18:52Тут прозвучала хорошая идея — оплачивать тестовые.
Но если человек и за деньги откажется, то наверное ему не нужна работа.
И ещё нужно учесть, что сеньоров на Битриксе днём с огнём не сыщешь. Люди в этой сфере наверное довольно быстро уходят на другие платформыWhite_Scorpion
18.09.2018 02:06Ну тогда это даже не вопрос найма — если человек не заинтересован в принципе. Но тут опять же выходит мысль, сказанная ранее — к каждому сениору необходимо искать свой подход. Просто потому что там уже немного другие критерии подбора даже на "пойду или не пойду на собеседование".
Vasek18 Автор
18.09.2018 14:25Тут уже нужно, наверное, как-то заинтересовать его. Скорее уже важно прорекламировать свою компанию, чтобы получить выдающихся людей
White_Scorpion
18.09.2018 15:21В 95% случаях описание данной "рекламы" стандартно до тошноты, банальный пример — узнаёте?
Это настолько надоело сениорам, что проще и разумнее наверное в лоб говорить как то так:
- Есть стэк технологий: А, Б, Ц, Д и всё это вертится на Е
- Есть 4 человека на ПО: один — дятел, а ещё один периодически косячит, но с надеждой на исправление.
- В частях Б и Ц — трэш, угар и содомия — надо упорядочить.
- Код деплоим копи-пастом (что кстати было в том месте, где я работаю сейчас и введение git — законно считаю своим достижением =))
- Тестов нет. Никаких. Ни автоматических, ни хотя бы ручных.
- Менеджера два: один — гуманитарий, а второй вроде что-то шарит. Постить адекватные баги некому.
Надо разгрести — вот тебе зарплата 2000 евро сразу и каждый год поднимаем по 200 евро плюс премии. Чтобы получить премию надо родить ёжика против шерсти, но в целом мне два раза давали.
0xd34df00d
18.09.2018 21:58+1Но если человек и за деньги откажется, то наверное ему не нужна работа.
А если я отказываюсь от того, чтобы вечером в убере таксовать за деньги, и вместо этого по вечерам сижу дома и пишу опенсорс, то работа мне тоже не нужна?
Ну, скажем, выходной (на который у меня уже и так есть планы). Ну, скажем, я тестовую задачу буду решать 8 часов. Ну, оплатите вы мне по рейту, это где-то 5% моего месячного заработка. Это ощутимые деньги, но уже достаточно неощутимые на общем фоне, чтобы не сильно заморачиваться.
Вот если вы мне дадите нетривиальную задачу, да чтоб я её мог на гитхаб потом выложить с решением, да решать на хаскеле каком… Вот это другой разговор.
Да, у меня до сих пор где-то лежит чек на чуть меньше, чем одну двадцатую моей месячной зарплаты, который я никак не обналичу. Наверное, мне точно не нужна работа.Vasek18 Автор
18.09.2018 23:57Считаю нечестным давать нетривиальные задачи на собеседовании, а потом посадить человека поддерживать интернет-магазин 10000 уников в месяц
Демотивирует
McCow
17.09.2018 15:47Как тогда без траты времени понять, что соискатель нам подходит, и соискателю подходят условия, компания и должность?
Vasek18, эта процедура давно отработана, прописана в ТК, и называется «испытательный срок».
И не надо со стороны работодателя ждать двух-трёх месяцев, чтобы сказать соискателю: «Извините, Вы нам не подходите». Три дня и — adieu.
То же справедливо и для кандидата.
Как вам такой подход?
yoshka
17.09.2018 17:43Это работает, когда кандидат безработный. Иначе как-то неэффективно: ждешь человека 2 недели, пока он отработает на прежнем месте, принимаешь, оформляешь на испытательный, выдаешь задачи, а потом через три дня — adieu, следущий?
McCow
17.09.2018 17:49Бывает, что человек берёт на основной работе отпуск на пару дней-неделю.
Правда на позиции серьёзных специалистов я лично такого не припомню, но на позиции от джуниоров до мидлов бывало.Vasek18 Автор
17.09.2018 19:29Вы ещё не принимаете во внимание необходимость пройти проверку безопасности (у нас нет) и подписать все необходимые договора лично (у нас есть), например, о неразглашении
McCow
17.09.2018 21:44Логистику трудоустройства кандидата именно в вашей фирме я, разумеется, не принимал во внимание. Но то, что она (логистика) может меняться в соответствии с внутренним регламентом компании (кроме требования оформления ТК и собственно трудового договора) — это точно.
Просто я предложил ещё одну опцию. И, судя по другим комментам, я не одинок.Vasek18 Автор
17.09.2018 21:51Я очень рад, что с помощью статьи смог услышать чьё-то отличное мнение
Vasek18 Автор
17.09.2018 19:01Это тоже трата времени и довольно существенная, хоть и оплачиваемая. Плюс человек фактически теряет возможность остаться на текущей работе, так уже ушёл оттуда к началу испытательного периода.
Если конечно не превратить этот испытательный срок в однодневную экскурсию. Человек и с командой познакомится и может быть таск реальный сделает, а на текущей работе просто выходной возьмёт.
Некоторые компании практикуют такой подход и хорошо о нём отзываются и он даже озвучивался в комментариях под этой статьёй.
White_Scorpion
18.09.2018 02:12+1Мне нравится этот принцип, сам я с таким встретился однажды лет 5 назад и до сих пор работаю на этом месте. То бишь меня опросили с чем я имел дело, опросили чего я жду от работы… И понеслась.
Этим кстати — решается ещё одна очень важная вещь — проверяется как человек вливается в коллектив. Просто он может писать прекрасный код, но на деле быть несколько неадекватным (для коллектива) и проверочный срок — решает эту проблему. А это, порой, важнее, чем красивый код. Потому что подучить коду или поменять привычные практики профессионал сможет, а вот психологически "не быть говном" — не факт.Vasek18 Автор
18.09.2018 14:27Да, личные качества, как минимум в IT, имеют всё больший и больший вес
Arranticus
18.09.2018 14:31А как это чувствуется со стороны кандидата, которому отказывают в итоге? На следующем собеседовании ему придётся объяснять, почему работал где-то неделю или месяц. Смотрится не очень, хотя, может, просто не его профиль оказался.
Спрашиваю потому что приходилось увольнять человека с испытательного срока и было как-то совестно, что испортили ему трудовую.
Deerenaros
17.09.2018 18:36+1Как минимум, потому что стоит обращать внимание на прошлый опыт. Github или даже проекты в папочке на флешке. Не столь важно, но почти любой разработчик имеет достаточно большое портфолио. Плевать на NDA, потому что по большому счёту оно ничего не значит, в военке этот код вообще не попадает по гос. тайну (да, да, под гос. тайной параметры кода, тогда как алгоритмы просто всем известны); но даже если каким-то чудом весь код под NDA и у человека физически нечего представить (или он боится), то можно ему просто поверить. Испытательный срок регламентирован трудовым кодексом и приносит намного больше пользы, чем условное тестирование. А за примерами далеко ходить не надо, не так давно пришлось искать работу и в первую же неделю нашёл 4 предложения в практически разных сферах: две военки, один геймдев графики и один геймдиз. Одна военка слилась по времени (так и не перезвонили), другая предложила небольшое тестовое задание на «отсеим дурака», геймдев решил обременить меня рисованием 3D-текста в OpenGL, а геймдиз небольшой анкетой и тремя (!) собеседованиями. В итоге геймдиз не выдержал зарплатной конкуренции, а вот нарисовать 3D-текст я не смог. Это и так не тривиальная задача, а усложнилась она библиотечным адом и мигрированием под linux. В итоге я за час разобрался в API, сформировал 2D-фигуру которую вот хоть рисуй, но потом тупо устал: у меня уже было два предложения, а зарплаты были примерно одинаковые (на военке чуть-чуть меньше, но 100% белая и удобнее местоположение).
По поводу задания, считаю, что добился очень не плохого результата, однако показалось немного грустным выполнение сложной профессиональной задачи за бесплатно, причём в Интернетах не найдёте особых туторов по рисованию 3D-текста. Если что, по условию задачи надо было именно разместить вершины в пространстве, шейдером или ещё чем-то. Это очень неприятный для меня опыт, который никому не пожелаю. Мысли были именно такие, как чуть ниже: «Да блин, я уже всё доказал, ну их лесом». Позвонил, сказал что не справился, после чего позвонил и сказал что согласен. Но уже другим ;) При этом довольно сложная область, это embedded systems со своей спецификой, к тому же увлекаюсь в матан, жаль data science за отсутствием опыта не найти. Думаю на битрексе конкуренция ещё жёстче, да и вы не гугл/яндекс. А так, такие задания это удел студентов (или вчерашних студентов), которым реально нечего делать.
P.S. У вас же есть какая-то статистика по отказам от тестового задания. Довольно интересно, какой процент отказывается от его выполнения? Потому что не первый раз отказываюсь и ничего не теряю, так как всегда были варианты без подобного бреда. И ещё, какие у вас зарплаты, если индивидуально — то какая вилка. И если не секрет, то ваш гонорар интересен ещё более, хотя по статье и имею представление.Vasek18 Автор
17.09.2018 19:40-1Не поверите, но ни одного отказа. Я закладывал в задание возможность достойно «накалять» его за буквально 3 часа. Это не учитывая того, что можно использовать свои наработки и задача совсем не уникальная.
Самым тяжёлым случаем у нас было, когда один соискатель на зп сеньора запросил 10 дней, а потом сдал слабенькую работу. Но тут проблема была в том, Битрикс не был его профилем, буквально 1 проект в портфолио и то считай вёрстка; он уже получал очень неплохие деньги на другом месте, как никак ему было под 40 лет уже. Мы бы не смогли предложить такой же уровень зп и для обоих это был бы проигрыш. Устное собеседовании всё подтвердило и мы могли бы максимум 40к предложить.
В целом я вас понимаю. При одинаковой зп, можно пойти и по пути меньшего сопротивления и выбрать компанию без тестового. И возможно действительно многие так и делают
0xd34df00d
18.09.2018 22:00+1Если он таки имеет гитхаб, то попросить его скинуть то, чем он больше всего гордится.
Это даже честнее, разумнее и релевантнее, чем тестовые задания.Vasek18 Автор
19.09.2018 00:07Кстати, всегда терялся, что прислать, так как что-то тривиальное показывать не хочется, а сложный код в принципе не пишу.
В последние разы присылал домашние проекты, так как использую в них другие технологии и подходы, чтобы с ума не сойти от Битрикса. Но это тоже не очень правильно, так как не показывает мой уровень по основному направлени
ErnestMiller
17.09.2018 19:05Рынок толковых программистов под 1С-Битрикс на столько узкий, что отпугивать их многочасовым тестовым заданием — это просто как-то беспечно. Всякий неадекват на собеседованиях отсеивается после 10-15 минут простого общения и простых технических вопросов. А нормальные программисты всегда заняты, и если они в поиске работы — это означает, что они еще где-то работают и рассматривают как минимум 3 нормальных предложения. Так что если пришел нормальный программист, который нормально ответил на основные технические вопросы, да еще и зарплата его устраивает — это уже повезло.
Vasek18 Автор
17.09.2018 19:09Вы очень правы, что толковых специалистов на Битриксе очень мало.
Я на самом деле думаю набирать больше джунов, чтобы выращивать их.Лишь бы хотя бы сертификаты какие-то были сданы и знал бы как компоненты подключать. Но таких наверное только фуллстеков брать, так как чистый бек будет долго сидеть без задач иногдаwarhamster
18.09.2018 12:39Учить джунов — так себе выход: те, кто с мозгами, мало-мальским кругозором и минимальными амбициями — быстро поймут, что битрикс — это профессиональный тупик, и уходят. Довольно специфическая мотивация должна быть у человека, чтобы целенаправленно заниматься именно битриксом. Тут либо ставить текучку кадров на конвейер (тоже вариант, много где работает), либо искать вот таких специфических людей — они есть, но их, да, крайне мало.
Vasek18 Автор
18.09.2018 12:40+1В Битрикс идут ради денег и только. Профессионального развития там, и в правду мало.
Так что, чтобы остановить текучку придётся нужно будет развивать само место работы. Что-то типа hr-бренд
Madeas
17.09.2018 10:30Спасибо за статью.
Я конечно далек от тим лида, но как веб-разработчик, извлек для себя несколько полезных советов, которые помогут не наступить на грабли, если когда-нибудь попаду в команду.Vasek18 Автор
17.09.2018 10:33Я рад, что кому-то помог статьёй.
То есть вы сейчас фрилансите? Меня достало это за 2-3 года, так как приходилось самому продавать, самому «выбивать» деньги, заниматься бухгалтерией и главное не с кем поговорить о программистком.
Berkof
17.09.2018 11:10Статья понравилась, надеюсь было полезно почитать про чужой опыт… Поделюсь своим — на кодревью, если вы видите, что одни и те же люди регулярно делают одни и те же косяки и вы вынужденны как обезъяна править одно и тоже — значит люди не тянут сразу исправиться. Нужно и от них побольше усилий получить и задачу облегчить.
Для первого подойдёт разговор с глазу на глаз типа «я с твоими пуллреквестами уже пальцы стёр, давай поговорим, буду голосом рассказывать» и расскажите человеку штук 5 (не больше) самых частых его ошибок… Подробно, чем это мешает, почему это не правильно, ссылки на статьи/стандарты, репродьюсер бага или сравнение по производительности/потреблению памяти… вообщем что угодно, чтобы он ещё неделю твёрдо помнил, что так делать не надо и подсознательно не хотел попасть на новую лекцию… ругать не надо, именно прочитайте лекцию…
А с другой стороны — не надо сразу на всё подряд внимание обращать — русскому/английскому языку вы точно человека не научите через PullRequest&Review, алгоритмы не вобьёте… а вот скобочки расставлять, лесенку делать или пользоваться несколькими библиотечными методами — можете, вот и ограничьтесь только 3-5 косяками (ну если нет чего-то совсем уж тушисвет), но отмечайте их с неотвратимостью автомата и заставляйте править — ошибки уйдут за месяц, а как только не станет этих — можно браться за другие.
Да, время жрёт кучу.justmara
17.09.2018 13:05Скобочки/лесенки хорошо приживляются через code analysis. Вроде как и не лид зануда, а беспристрастная машина при поддержке авторитета сонм разработчиков, разработавших правила.
Vasek18 Автор
17.09.2018 15:41Мы просто посадили всех на шторм и показали как делать автоформатирование.
На самом деле пока проблем не возникало с форматированием кода. Но если ситуация будет ухудшаться, то я решу её через хуки гита и форматирование через php-cs-fixer. На прошлой работе так делал в качестве эксперимента. В результате все пишут как хотят, а перед коммитом код сам форматируется
Vasek18 Автор
17.09.2018 13:14К форматированию кода я вообще не придираюсь принципиально. Замечания всегда какие-то логические в духе «убрать запрос в цикле». Если что конкретно запросы в цикле у нас уже никто не делает, просто привёл для примера)
Идея про внушения на созвонах довольно интересная, спасибоApeCoder
17.09.2018 16:47+1Именно чтобы не заниматься форматированием нужен автоматический стайлчекер
Vasek18 Автор
17.09.2018 19:23У нас ребята просто стараются не форматировать весь файл при работе, а только тот кусок, над которым работают. К тому же у всех в Шторме правила настроены очень общие, чуть ли не пср-2. В принципе сейчас это решает проблему полностью.
Но если что, повесим автоформатирование на хук коммита
klim76
17.09.2018 12:52“взяли миддлом/сеньором/старшим — стал миддлом/сеньором/старшим”. Когда я начал искать работу, мне бы хватило и позиции сеньора (и её я искал), но предложение тимлидства меня перекупило и немного польстило.
Процесс взятия лидом не раскрыт. Ведь далеко не всякий лид — сиьер, как и не любой синьер — лидVasek18 Автор
17.09.2018 14:45Правда. Иногда разработчики делают выбор между углублением в разработку и уходом в руководители довольно рано.
На эту позицию у меня было очень интересное собеседование. По сути это был двух часовой разговор в свободной форме про технологии, развитие фирм, команд, про работу по скраму, про Битрикс как про платформу и его альтернативы. Каких-то классических вопросов, типа, что такое позднее статическое связывание не было. Предложение мне сделали довольно быстро, но испытательный срок, конечно, был.
По сути сыграла просто моя готовность и желание быть лидом, так бы меня взяли старшим разработчиком, мб даже с сопоставимой ЗП.
propell-ant
17.09.2018 14:14Смотрю на комментарии, у меня одного что-ли сомнения насчет соответствия названия должности «тимлид» и фактических обязанностей/проделанной работы?
Всегда казалось, что тимлиды появляются в структуре подчиненности тогда, когда появляются относительно независимые команды, с которыми начальник отдела (или департамента) разработки сам уже не успевает управляться.
Мне кажется, вся статья про то как человек с навыками сеньора поставил работу отдела разработки, фактически совмещая обязанности начальника отдела разработки и тимлида.Vasek18 Автор
17.09.2018 14:52О, очень хороший комментарий.
Это одна из причин, почему я писал статью. Должность тимлида довольно туманна и разнится от компании к компании, об этом ещё свидетельствует наличие одной большой конференции почти полностью посвящённой вопросу определения.
В нашей компании я тимлид, хотя по мало чего бы поменялось, если бы должность называлась старший разработчик или технический директор.
Я написал статью, чтобы тимлиды, техдиры, разработчики, hr, руководители, менеджеры увидели мои обязанности и это как-нибудь дополнило их представления. Плюс, чтобы кто-то в комментариях сказал: «это и это не обязанности тимлида, а вот это вот наоборот нужно добавить, да и вообще у нас так: ...». Поэтому мне было очень важно слово «Тимлид» в заголовке.
andreysmind
17.09.2018 16:29Могу посоветовать почитать "Проект Феникс" или еще лучше "Цель", так как раз речь идет о ситуациях похожих на описанную в статье.
elliadan
17.09.2018 16:40Vasek18 большое спасибо за статью! Очень жду продолжения!!!
Если не трудно, проккоментируйте чуть подробнее вот это:
я ежедневно лично проверяю все оценки и постановку всех новых задач
Как много времени у вас это занимает? Возможно, я не правильно представляю кол-во задач у вашей команды, но на первый взгляд это воспринимается как «я пол дня сижу и проверяю задачи и так каждый день».
во все задачи закладываем время на тестирование, общение и сдачу клиенту
Вы как-то объясняете клиенту ценообразование работы целиком? Если да, то как вы аргументируете «надбавку» за общение и сдачу?
Спасибо!Vasek18 Автор
17.09.2018 19:19Как много времени у вас это занимает?
До часа. Хотя я изначально боялся, что действительно по полдня буду сидеть. Но, во-первых, проекты редко меняются и кодовая база по большей части в голове, во-вторых, часть задач нужно просто посмотреть, что есть вся необходимая информация и здесь многое отсеивается, в-третьих, если за примерно 15 минут мы не сможем дать оценку, то мы создаём отдельную задачу под оценку, как, например, интеграция с очередной crm.
Вы как-то объясняете клиенту ценообразование работы целиком?
Ценообразование у нас очень сложное и абстрагирован от этого. Мы индивидуально подошли к каждому клиенту. Но мы и все наши текущие клиенты понимают, что работа над задачей это не только стукание по клаве, но и общение, выработка решения, обсуждение вариантов с клиентом,… Тем более, что с помощью общения мы часто ещё и удешевляем задачу, предлагая альтернативные подходы и подсказывая идеи.
Фишка же не просто время в деньги перевести, а улучшать клиентский бизнес.
werklop
17.09.2018 18:48+1Не воспримите как негатив, но: кмк, в большинстве случаев вам просто не хватило воли, чтобы все ускорить и сделать правильно. Например:
1)Инструкции — дать задание, чтобы каждый программист выделял время на их создание до тех пор, пока важных для разработки вещей не будет в электронном виде
2)проблемы с гитом — какие могут быть проблемы? вы же наверняка видели, как и где они работают. Если кто-то не в IDE(а не дай б… в простом текстовом редакторе без автокомплита и поддержкой гита), то путь осваивают и учатся в том же шторме и там же использовать гит. Также не должно быть здоровенных коммитов и длинных задач, если это не исследовательские, используйте композицию
3)«но если твои коллеги саботируют регламенты, работают “по привычке” и не используют новые инструменты» — вы серьезно? перед такими работниками просто надо ставить выбор — либо работаешь с нами, либо досвидос. С вашей стороны, как лида, вы должны периодически общаться с подчиненными, тет-а-тет, особенно, если видите какие-то проблемы в работе. Никаких сюсюканий и детского сада, люди взрослые, ответственность должна быть у каждого!
4)«На два стула не сесть» — и не надо. У каждого есть должностные обязанности, на такие случаи кладется табу, он же болт на тех, кто пытается принудить сесть на эти оба стула
В общем и целом, то, что вы внедряется, вещи хорошие, приучать людей к хорошему надо, не взирая на их текущую зону комфорта(поскольку в итоге вы их пересаживаете в более комфортную зону), но делаете вы слишком мягко, неуверенно что ли… Удачи!Vasek18 Автор
17.09.2018 19:54Спасибо за конструктивность
Я думаю, что как минимум отчасти вы правы по поводу мягкости. Сейчас мы вводим систему штрафов (не денежных) и она саботируется оштрафованными (было бы странно будь наоборот), и тут нужно уже как-то понажимать на коллег.
Проблемы с гитом были для меня вообще шоком. Мы даже экран иногда шарили, чтобы отловить проблемы.
У нас был один парень на Эклипсе и в какой-то момент пришёл сеньор(!) на нотпад++. Все остальные были в шторме, но как мне показалось, один иногда пытался работать через консоль, типа «олдскулл». Парень на Эклипсе правда ушёл уже какое-то время назад, но у него были другие проблемы.
Последней каплей было, когда я увидел пару логов в стиле «решал проблемы с мерджем» на полтора часа. Но тогда до меня уже дошла идея пятничных созвонов и буквально за 2-3 созвона мы пересадили всех в шторм и показали как решать конфликты. Сейчас по крайней мере уже пару месясцев не упоминаются проблемы с мерджами и потерей кода на созвонах, хотя кроме этого больше ничего и не было сделано.
Следующим шагом наверное будут пулл-реквестыwerklop
17.09.2018 20:09По поводу штрафов — отчасти это хорошо, но должны быть не только кнуты, но и пряники.
Про гит — с одной стороны пофиг, кто как работает, но есть устоявшиеся практики работы в IDE, которые облегчают и ускоряют мерж(для того они и написаны). «решал проблемы с мерджем» — после такого надо сразу подходить и давать выбор, либо пересаживаешься на IDE, вот тебе пару дней на освоение, либо на не по пути.
«пулл-реквесты» — а что вам мешало прийти и с первого(ну ладно, хотя бы через месяц) сказать типа: «Все, все работаем по типу гитхаба, используем гит флоу, пока кодревью я не закрою, задача в тест/прод не уходит». Соотв-но, все ваши замечания по кодревью будут устраняться, иначе задача будет превышать сроки. Демократия и равенство в коллективе хорошо, когда самостоятельность/проактивность и отвественность каждого не «на дне», а покамест вы начальник этого стада. Вот когда воспитаете подопечных, то можно будет и подкармливать «печеньками». Но только эти печеньки заранее озвучить, возможно для каждого свою, чтобы была прозрачность и мотивация.Vasek18 Автор
17.09.2018 21:42Мы очень хотим ввести «пряники», но к сожалению пока было не из чего их делать. Именно по этой причины мы решили ввести «кнуты», потому что все деньги на премии уходили на оплату работ, которые не оплачивал клиент, если точнее, на переработки по задачам.
Мы решили ввести какие-то наказания, потому что одни и те же люди, регулярно превышали свои же оценки или растягивали часовую задачу на весь день.
Мы сразу же обсудили, что не будем штрафовать деньгами, потому что как минимум пока не можем ими поощерять. В качестве штрафов мы решили ввести обязательные доклады/лекции, которые хотя бы косвенно относятся к причине превышения.
а что вам мешало прийти и с первого(ну ладно, хотя бы через месяц)
К сожалению, недостаток времени. Каждый программист писал код практически по 8 часов (минус созвоны), в том числе и я. И всё равно не успевали.
Сейчас вроде бы стало полегче. Думаю попробовать ввести практику совместных кодревью в конце дня.
Да и если быть честным, то на Битриксе трудно писать совсем уж плохой код.werklop
17.09.2018 21:52+1потому что все деньги на премии уходили
И тут мы приходим к тому, что либо ваши сотрудники некомпетентны и не умеют планировать свое время(в этом случае возможно стоит пересмотреть материальное вознаграждение, а также делать декомпозиции задач, если они реально большие), либо сотрудник не понимает или не хочет понимать, что он приносит деньги, а не просто кодит и хабр читает(тут либо расставаться, либо проводить беседы)
в том числе и я
В смысле вы? Вы же устроились тимлидом, вот и тимлидьте, не лезьте на «второй стул». А так вы только распыляетесь, а картину видите только с опозданием, потому и времени на правильные решения уходит многоVasek18 Автор
17.09.2018 22:02И тут мы приходим к тому, что либо ваши сотрудники некомпетентны и не умеют планировать свое время
Задачи всегда декомпозированы, конечно. Иначе они превращаются в эпик.
Считаю, что нет ничего более демотивирующего, чем денежные штрафы на работе или понижение ЗП. Поэтому решаем проблему развитием кадров и пробуем разные подходы для этого. Увольнять пока не приходилось и, слава богу, сейчас нет таких кандидатов
В смысле вы? Вы же устроились тимлидом, вот и тимлидьте, не лезьте на «второй стул».
Да, я упомянул этот момент в статье. Про два стула
Но в любом случае полностью переставать программировать я, наверное, не буду
MacIn
17.09.2018 21:01сама разработка тоже была не ахти:
где-то что-то разрабатывалось даже вне гита
Скажите, как вы определили, что команде нужна децентрализованная система контроля версий, а не что-то иное с master репозиторием? Что-то кроме «ну все же используют гит, и это все знают»? Это связано с workflow именно этой команды?Vasek18 Автор
17.09.2018 21:50Нужно просто не терять код, не перезаписывать чужие правки на проекте, работать изолировано и иметь актуальную кодовую базу, хранить устаревший код для справки, знать, кто что исправил и зачем, хранить удалённую копию кода на случай выхода человека/компьютера из строя. Как тут без гита с удалённым репозиторием?
MacIn
17.09.2018 22:17Нужно просто не терять код… иметь актуальную кодовую базу, хранить устаревший код для справки, знать, кто что исправил и зачем,
выполняется и централизованными скв.
не перезаписывать чужие правки на проекте
Почему? Любая правка может быть перебита новой правкой. Как было до — для этого есть неизменяемая история.
работать изолировано
Часто приходится переключаться с задачи на задачу, бросая на полдороге?
хранить удалённую копию кода на случай выхода человека/компьютера из строя.
Опять же, это позволяет любая скв.Vasek18 Автор
18.09.2018 10:43+1Мне кажется у нас недопонимание
где-то что-то разрабатывалось даже вне гита
В данном случае не значит, что использовалась какая-то другая система. Тут говорится про проект, где был один сервак на всех и программисты по очереди правили файлы, подключаясь по фтп. То есть не было вообще никакой скв, программисты просто правили файлы в надежде, что сервак не будет крашится и всё.MacIn
18.09.2018 14:20Ну так если бы было сказано «программисты даже не использвали систему контроля версий!» — вопросов бы не было. Была названа конкретная система — «что-то разрабатывалось даже вне гита». «Гит» пока что — не имя нарицательное, это название конкретной системы конкретного вида. Поэтому я и спроил — отчего речь именно о гите, а не, скажем, svn или чем-то аналогичном.
the_coder
18.09.2018 23:47Хорошая статья. Пишите еще.
Практически один в один как у нас в отделе разработки.
Мы также пытаемся внедрить scrum.
Как вы с разработчиками оцениваете время реализации задач в спринте?Vasek18 Автор
18.09.2018 23:49Спасибо
40 часов — время на координацию — буфер на внеплановые — риски неправильной оценки. Последнее скорее небольшое округление вниз
imanushin
Спасибо за статью. И сразу вопрос про:
На хабре уже же обсуждалось, что подобный подход отсеивает людей, которые:
=====
Другой вопрос: а вы сами стали бы решать задачу? Несложную, на middle уровень, например, lock-free алгоритм очереди с возможностью итерирования и т.д.?
=====
Считаете ли вы это коррупцией или кумовством, что наняли в свою команду друга? Был ли при найме конфликт интересов? Он тоже решал задачу, или так взяли?
=====
Какую часть своего времени вы программирует? И как вы все-таки считаете, вы уже менеджер среднего звена, или же еще team lead?
=====
А какая премиальная часть за взятие ответственности? Если ноль, то рациональнее не брать ответственность. А если берут — то нет ли проблемы с работой, если, как мы видим, люди явно поступают иррационально с проектом?
=====
Как вы решаете проблему с недоверием сотрудникам к вам?
Vasek18 Автор
Какой большой комментарий. Спасибо за него
Про тестовое задание
Собеседование и тестовые обсуждались уже множество раз в том, числе и на Хабре. И у всех подходов есть свои минусы. Самым оптимальным, честным, точным, наверное, можно считать приглашение на целый день в офис, где соискатель будет работать, так как будто бы он уже часть команды. Но даже он имеет проблемы с теми пунктами, которые вы описали. Например, серьёзно работающий человек не сможет найти целый день на работу на другую фирму.
Я считаю, что в конкретно нашем случае тестовое задание очень важно, так как Битрикс требует очень много специфических знаний.
Плюс Битрикс в 80% случаев подразумевает разработку интернет-магазинов и довольно скучные задачи, поэтому считаю нечестным перед кандидатом проверять его общие знания и логику, а потом давать какие-то однотипные задачи. Поэтому тестовое задание по сути является разработкой формы заказа и у соискателя есть лишний шанс подумать хочет ли он заниматься этим 40 часов в неделю, так как не всем такое по душе.
Сам я бы решал тестовые задачи, что собственно и делал некое количество раз
Про друга
Тут выгода для меня/нас была в том, что, во-первых, я мог очень быстро связаться с соискателем и доступно объяснить, а, во-вторых, я успел с ним сделать несколько проектов и уже знал его уровень.
Но чтобы избежать кумоства и чего-либо подобного, я не принимал никакого участия в его собеседовании и принятии решения о приёме на работу. Но это частный случай нашей компании. Наш директор имеет довольно уверенные технические знания, поэтому он мог принять решение самостоятельно.
Про самоощущение
На сегодняшний момент где-то половину своего времени я пишу код, как рядовой программист, считаю это важным для себя и компании. Остальное время по большей части тоже «техническое»: код-ревью, консультации ребят, оценки задач, выбор подходов. Поэтому считаю себя лидом, а не менеджером.
Про ответственность
На самом деле всё начинается с таких вещей как «Этот код писал не я, я его не буду править», «Я решил не подключать библиотеку А, так как думаю, что это не в моей компетенции», «У меня на тесте не повторилась ошибка, на бою не буду трогать админку»,…
Довольно эфемерный момент для «начисления очков», поэтому премирования нет.
Сам я борюсь с этими стопами через разрушение мифов и страхов у ребят.
Про недоверие
На самом деле не сталкивался с этой проблемой.
Но во второй части расскажу поддержание авторитета. Довольно интересный момент
imanushin
Спасибо !
Это особенно интересно
Siddthartha
Проблема с тестовым заданием обычно всего одна — оно должно быть оплачиваемым по полноценному рейту. Тогда соискатель с удовольствием его выполняет (особенно с собственной оценкой времени))).
Это одновременно и сдерживает работодателя от раздутых заданий, и позволяет соискателю спокойно показать свой уровень без нервотрепки и стресса ("я на них три дня потратил, а они мне отказали").
Vasek18 Автор
Кстати, хорошая идея.
Нужно будет обсудить внутри фирмы.
Так по идее можно и переманивать людей
SergioPredatore
Поддерживаю!
На одном из собеседований на удалёнку, когда мне предложили сделать тестовое задаение, я прямо сказал: бесплатно делать не буду. После чего мы обсудили критерии приёмки, стоимость и сроки. Результатом стало долгое плодотворное сотрудничество.
Собственно я бы хотел соискателеям дать совет: уважайте себя и цените своё время, адекватный работодатель это оценит, а не адекватный… а он вам нужен?
jobgemws
Полностью согласен с комментарием.
Также добавлю, что пройдя 100+ собеседований в разных компаниях (как успешно, так и не успешно, с согласие на работу, так и с отказом на работу после приглашения), а также при проведении собеседований хотя бы несколько десятков раз, вырабатывается навык, когда в течении 15 мин или меньше точно можешь сказать, что тебе сотрудник/компания не подходит, а еще за 30-45 мин понять-допускать к испытательному сроку/идти на испытательный срок или нет.
За 30-45 мин как раз идет диалог-что делали, как решали проблемы и т д и т п, т е даже без тестов-просто в режиме свободного диалога.
Все остальное, особенно задачи на более, чем 2 часа должны быть уже на испытательном сроке, где стороны обоюдно присматриваются друг к другу, а не одна из сторон (часто этот маленький, но важный момент забывают и сами работодатели).
Если работать надо в команде, то обязательно на собеседовании кроме руководителя должен быть 1-2 сотрудника из команды, с которыми чаще всего нужно будет взаимодействовать, чтобы коллеги определили (да и сам кандидат) для себя на сколько подходит человек в плане коммуникаций, знаний и нет ли интуитивного отторжения или еще чего.
Вот и все
А минусы есть по обеим сторонам, важно понять на какие компромиссы и уступки можно пойти и что можно улучшить опять же с обеих сторон, т к предела в совершенстве нет.
Vasek18 Автор
Вы проходили собеседования больше 100 раз?
jobgemws
За 6+ лет своей ппофессиональной деятельности да, т к это мое хобби и в среднем хожу на собеседование 2-3 раза в
jobgemws
месяц
bro-dev0
Где вы столько контор находите куда собеседоваться, и не смотрят на вас странно когда раз в 3 месяца в одно и тоже место идете, так же не боитесь что вам дадут согласие, а вы откажетесь, а вам через 3 месяца нужно менять работу, а там уже обиженные за ваш отказ сидят.
jobgemws
Я в одно и тоже место редко хожу
Компаний много от мало до велико и необязательно IT, где нужна разработка теже кредитные органтзации, логистика, торговля и т д и т п
Компаний тьма
Все в основном через spb.hh.ru, реже через знакомых и еще реже через Хабр и Гитхаб
jobgemws
Какие обиды?
Это рынок и обе стороны рискуют
И если брать в целом, то можно вывести жизненный цикл жизни специалиста в рамках одной компании или одного проекта, которая заключается в определенном стеке технологий, предметной области, подходах к разработке, поддержке и оптимизации.
Данный цикл длится по разному, но обычно составляет 1, 3 или 5 лет, реже 10 лет, т к более 5-ти лет находится в одном проекте или более 10-ти лет вариться в одной предметной области чревато для компетенций относительно рынка.
И не стоит забывать, что профессия-это еще и хобби и страсть к познанию, а работодатель-это спутник и инструмент, позволяющий знания применить в практике. Итого: Вы выбираете себе удобный и нужный инструмент, исходя из Ваших пожеланий и потребностей профессионального роста, равно как и работодатель выбирает себе более подходящего по его мнению сотрудника.
С компанией, которая чего-то боится мне не по пути, равно как и сотруднику, который боиться вырваться из зоны комфорта сложно осознать, что все на самом деле очень просто и нет ничего сложного.
На счет количества вакансий-напр, .NET или MS SQL в spb.hh.ru наберите поиск и каждую неделю там новые вакансии и их в среднем сотни за месяц от нескольких десятков компаний, а за год-более сотни таких компаний. И потому 100 компаний за 6+ лет это еще немного (по крайней мере исходя из статистики). Но все охватить-такой цели не стоит. Однако, если хочешь держать руку на пульсе, что происходит на рынке, как не нужно проводить собеседование, анализировать и понимать что от тебя хотят и что скрывается в несказанности рекрутером, то считаю просто необходимостью походить по собеседованиям (особенно тем, кто проводит эти собеседования и сидит на месте более 10-ти лет). Лишним не будет точно, а за частую и полезно в развитии как коммуникабельных способностей, так и телепатических)
jobgemws
Да и к тому же, частотбывает, что ты хочешь в компанию, но тебе отказывают либо сразу, либо на последнем этапе собеседований. И сколько таких ситуаций было-я же не обижаюсь.
Грамотный работодатель не заканчивает процедуру поиска, пока не начнется по факту первый рабочий день нового сотрудника, и у работодателя всегда есть в заначке еще кандидаты в случае непрохождения новым сотрудником испытательного срока (инициатива может быть как от работодателя, так и от сотрудника-не стоит и этот момент забывать).
Агалогично и у специалиста должны быть запасные варианты (правда здесь немного похуже, т к единицы из компаний понимают эту необходимость, а большинство просто обижаются или боятся раз их оставили в заначку)
jobgemws
На счет увольнений-здесь не такой большой опыт (всего несколько раз, а не десятки), однако конечно если решили сами уволиться, то работу нужно довести до логической точки и заранее в фоне подготовить почту для быстрой передачи знаний, а также сообщить работодателю о своем решении как можно раньше, а не за 2 недели, чтобы и у того было время откорректировать рабочий процесс с учетом Вашего ухода.
Также можно оставить отзыв о работодателе и договориться о рекомендациях Вам.
jobgemws
Почта=почва (в телефоне в метро автозамена сработала)
Главное-не сколько Вы прошли собеседований, ни сколько по времени Вы проработали, а главное-что Вы осознали, что исследовали, что сделали, чему научились сами и чему научили коллег
Vasek18 Автор
Мне тоже нравится ходить по собеседований ради самих собеседований. Посмотреть как люди живут, что предлагают, какие проблемы хотят решить, где офисы снимают.
Правда уже несколько лет не ходил никуда
jobgemws
Главное-не забрасывать, хотя бы 1 раз в полгода (хотя все индивидуально).
Vasek18 Автор
Ну хотя бы 1 раз в полгода я сами вакансии смотрю, чтобы быть в курсе, что сейчас нужно на рынке
jobgemws
Это да
Но смотреть одно, а попасть на собеседование и пообщаться-совсем другое
Lissov
Позволю себе ответить с моей точки зрения.
Что и показывает, что компания должна реально оценивать свой уровень. В Амазоне — да, в местной конторе — нет. Если место интересное и хочу эту работу — я делал.
По статистике, мы сообщали кандидатам о тестовом задании после первого разговора. На больше сотни кандидатов, было пару недовольных (одного при этом наняли) но всего пару несделанных заданий и ни одного явного отказа делать.
Бонус всегда приятен, да и определенные усилия со своей стороны есть :)
А серьезно, если речь не про госконтору, то главное результат. Если человек полезен команде, то и я, и команда, и руководство заинтересовано, чтобы нанять наиболее комфортного мне как тимлиду человека. Потому если я на 100% уверен — посоветую так что друга возьмут. Но это палка о двух концах — если не сработает, то доверие ко мне будет серьезно подорвано, потому я тут осторожен.
Бонус в данном случае вторичен, но опять таки если начальство устраивает — то почему бы и нет?
Премии не всегда должны быть деньгами. Правильная похвала тоже работает. Сотрудники хотят понимать, что лид их ценит и доверяет. Опять таки это повышает шансы на развитие или хотя бы на неувольнение при сокращении бюджета.
Ну и далее дополнительные вещи — команда и менеджмент в целом гораздо терпимее к ошибкам того, кто берет ответственность и делает результат. А ошибки бывают у всех. Ну и вообще быть на хорошем счету у руководства выгодно.