Пользователь
0,0
рейтинг
31 июля 2013 в 09:25

Управление → Жизнь управленца, кадр 2, жесткая воля recovery mode

После размещения первого своего поста, я получил то, что и ожидал.

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

В этом посте, я бы хотел поговорить о «воле» руководителя компании. Когда вы создаете компанию, вокруг вас соберется достаточно большое количество людей, которые будут считать себя «особенными», приближенными к вам и стараться защищать свои собственные интересы.

Мы уже говорили о том, что в компании разработчиков, всегда возникают неформальные лидеры, которые поддерживают свои позиции толкованием различных стандартов и рассуждениями о «чистоте» разработки, стандартизированности процессов и тд и тп. Я упоминал, что количество подобных людей должно быть строго контролируемо вами, и база знаний должна быть равномерно распределена между всеми участниками вашей команды.

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


Лидер


Я уже упоминал, что в компании необходимо убирать слишком большое количество «теорестов», искусственных авторитетов, которых вы не можете контролировать и на кого очень сложно полагаться. Очевидно, что как только вы разрушите теократию теоретиков сразу возникнет пустота, которую необходимо заполнить, в противном случае получится только хуже. Пустоту должны заполнить или вы сам, или ваш менеджер.

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

I. Не надо пугать людей

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

  1. Нарушение сроков и другие операционные ошибки. Поймите, сроки всегда будут срываться. Всегда. Везде. В любом проекте. Поэтому у вас с тимлидом должна быть договоренность о приемлемом срыве срока. Сроков должно быть несколько: «срок разработчика», «срок тестера», «внутренний срок», «срок внутренней приемки», «срок клиента». При этом любой срок далее «срок тестера» должен быть известен только вам и тимлиду. В таком случае, при 10%-30% нарушении срока, вы все еще успеваете выполнить свои обязательства. Но в любом случае, когда нарушает срок разработчик он должен быть наказан.

    Самый простой способ это ввод эталонных сроков. Любой тикет, задача, должны оцениваться самим разработчиком и либо старшим разработчиком, либо архитектором. Эталонная оценка, это оценка за сколько конкретную задачу выполнит ваш лучший разработчик. Затем вы определяете что от эталонной оценки может быть отклонение в рамках +-20(30)%. Если разработчик попадает в эти пределы, то все нормально, так как квалификация у разных людей, разная. Если разработчик выпадает за рамки оговоренных пределов, необходимо чтобы команда провела публичное обсуждение проблем, и на очередной ретроспективе публично разобрала случай данного разработчика, и если он виноват, нагрузила его общественными работами, скажем в виде предоставления доклада на тему где он «плавает». При этом доклад готовится строго во вне рабочее время.

    Ключевой момент здесь это то, что наказание сотрудника должно проходить в виде процесса, который выгоден всем. Сотрудник теряет свое свободное время, команда получает отличный опыт и доклад, сотрудник растет профессионально и вкладывает в свой интеллектуальный капитал. Слово наказание не совсем подходит к данному контексту, но, для собственного душевного равновесия лучше использовать именно его. Чтобы все понимали что наказания в компании есть и решения об их применении принимаете всегда вы. Вы должны утверждать любое наказание, которые понесет сотрудник.
  2. Лень. Если человек избегает работы, не желает расти, а вы находитесь в сложной ситуации и надеетесь, что он все таки начнет работать и поможет вам вытащить проект, снимите розовые очки. Вы не семья, и не родственники, вы не исправите человека. Если он любит больше времени тратить на разговоры, перекуры, концептуальные обсуждения, при этом его код всегда идет медленно и не очень эффективно. Увольняйте. При этом все люди должны понимать, кто и почему увольняет сотрудников. Даже если это лучший товарищ вашего ведущего разработчика, и вы боитесь что ведущий тоже уйдет, увольняйте. Первая ваша слабина, и вы уже не лидер в команде. Мне приходилось увольнять до целой команды с проекта, когда команда защищала одного абсолютно не адекватного сотрудника, бывшего их другом. Не бойтесь потерять людей, бойтесь потерять ключи к управлению командой. Кстати, из тех людей что я уволил, 70% попросились назад, покаялись и были взяты на работу.


II. Работайте

Когда в команде возникают проблемы по проектам, не «сливайтесь». Даже если вы не самый умный разработчик, вы опытный управленец, и часто, ваши решения могут помочь команде в решение тупиковых ситуаций. Не бойтесь предлагать организационные решения технических проблем. Всегда, в любых обстоятельствах, перед заказчиком берите всю ответственность на себя. Не важно кто у вас в команде «накосячил», перед заказчиком есть вы и только вы. Терпите, выслушивайте упреки и скандалы, потом уже общайтесь с командой. Не кидайте ваших сотрудников на решение проблем с разочарованными заказчиками. Все проблемы с проектами — ваши проблемы. Затем внутри команды, устройте разбор полетов, после решения проблемы. Пример, в одной сложной системе у нас начались проблемы с IIS он начал виснуть так как пошел пик нагрузок, вся команда сидела сутки и не могла ничего сделать, изменения в базу могли народиться только в течении недели, нужно было разделять базы, чтобы иметь возможность разделить правильно сервисы. Тогда я принял решение, что позвонил клиенту, силами наших администраторов развернул дополнительные аппаратные мощности, на них мы распределили нагрузки на сервисы, «купили» себе около месяца, и смогли решить проблему.

Берите на себя ответственность, не бойтесь участвовать в обсуждениях, предлагайте даже глупые идеи. Работайте. Вы должны пахать больше всех и люди должны это видеть.

III. Общайтесь со всеми сотрудниками.

Не закрывайтесь в кабинете. Запомните, вы должны стать лидером команды, не позволяйте неформальным лидерам, забирать ваш авторитет. И не потому, что вы злобный и хотите власти. А потому, что когда все неформальные лидеры отойдут от проблемы, один на один с ней останетесь вы. Когда руководитель всей моей группы разработчиков, вместе с двумя ведущими разработчиками, «слинял» из компании оставив долги по зарплате в размере 70 тысяч долларов США, я был вынужден решать проблему сам. Проблема возникла из-за того, что они решили отказаться от ведущего клиента, так как он был «козел», не шарил в стандартах, просил делать «говно»-вещи и тд и тп. Когда же они «просрали» все что можно, то просто сказали у нас проблемы, мы не знаем что делать, мы уходим. Неформальные лидеры, чаще всего «трусы». Они не будут думать о последствиях своих решений для других людей. Они «артисты» и вам, тупым управленцам их не понять. Поэтому будьте лидером, фокусируйте внимание сотрудников на себе.

IV. Будьте готовы.

Всегда будьте готовы ко всему. Что уйдут люди, что уйдет клиент, что проект выявит странные «черные ящики», которые вы не можете решить. Решения принимать будете вы. Только вы и никто кроме вас. Если вы уже решили стать руководителем, владельцем, компании разработчиков, будьте готовы к ассенизаторской работе. Да, это не справедливо, да это не фильмы с большими белыми офисами, красивыми секретаршами и улыбающимися людьми. Это жизнь. Жесткая правда жизни. Что в компании разработчиков, вы должны быть стержнем и никогда, ни при каких обстоятельствах не паниковать. Вы должны излучать уверенность и убеждать всю вашу команду что вы прорветесь через любые проблемы. Когда в очередной компании у меня было 2 разработчика, и к нам никто не хотел идти так как все было шатко-валко, я всегда говорил, что все будет хорошо, что к нам пойдут люди. Я был психологом, воспитателем, хотя сам не был ни в чем уверен. Иногда, хотелось сказать, блин да я тоже не знаю, что я должен что ли нянькой вам быть? Но уверенность, и целеустремленность всегда дают результат. В той компании мы создали такие условия, что сейчас у нас полный комплект и люди в очереди. А проекты, проекты какие в нашем регионе еще никто не делал.

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

Другие посты из этой тематики:
Жизнь управленца, кадр 1, не надейтесь на понимание

Жизнь управленца, кадр 3, коммуникации
Жизнь управленца, кадр 4, Планирование — Постановка задачи
Павел Пронин @undry
карма
0,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Управление

Комментарии (46)

  • +10
    нагрузила его общественными работами, скажем в виде предоставления доклада на тему где он «плавает». При этом доклад готовится строго во вне рабочее время.

    Не стал бы я работать в такой компании, в которой дают такую домашнюю работу
    • –3
      Поэтому мы и не работаем с теми, кому лень профессионально расти.
      • +3
        А дело не в профессиональном росте. Вы просто отсеиваете людей, чья трудоспособность может варьироваться от настроения или тревог или стресса. Лично знаю пару отличных программистов, которые по причине тревожного расстройства или неурядиц могут на пару дней уйти в штопор, причем в хорошем настроении их производительность взлетает. Ваш «доклад» только заставит их выбирать между вынесением личных проблем или проблем со здоровьем на суд публики, либо солгать. И то и то херово.
        • +2
          Согласен с вами на 100%. Я тоже знаю таких разработчиков. Но это люди другого порядка. Они работают очень быстро и эффективно, но бывает момент когда они могут «уйти в штопор». С такими людьми важно соблюдать «общайтесь с сотрудниками». Я выставил практику так, если тебе «херово», то просто напиши мне в скайп и скажи, мы подумаем что можно с этим сделать. Если это не часто, и ты потом всегда отрабатываешь свои косяки, в другие дни, на выходные, то все ок.

          Но если ты считаешь себя выше команды, и просто чувствуешь что ты отличный программист и можешь делать то, что тебе угодно, то мне не нужны отличные программисты. Мне нужны отличные профессиональные программисты. Перед которыми я выполняю обязательства и они передо мной.
          • +1
            Я думаю вам стоит указать и этот аспект в статье, потому что, честно говоря, иначе вы выглядете не в лучшем свете — в плане общения вы подошли только с негативной стороны.

            Как разработчик я считаю, что рабочий аспект общения стоит оставлять как можно рабочим и не примешивать в это чувство вины перед командой или насильно взращивать командный дух или ожидать лояльности. Это съедает эмоциональную энергию, которой и так хватает на внерабочее общение. Работа это не семья и не друзья, насильно мил не будешь.
            • 0
              Ну я постарался это осветить в разделе «III. Общайтесь со всеми сотрудниками». Может быть не до конца верно, освещу в следующих статьях. А так мой принцип простой, все контакты в вики, любой сотрудник в любое рабочее время, может мне стукнуть в скайп и обсудить со мной свои проблемы.
    • +1
      Если вы «косячите» и считаете это нормой, или любите получать денежные взыскания, то мы точно с вами работать не будем.
    • +2
      Мне кажется здесь страдает формулировка. По сути в agile или scram есть такая же вещь, только там это не так стрессово — на митинге говоришь почему не сделал в срок и какие были проблемы.

      А у автора совок какой-то.
      • –4
        Мне нравится русский язык. И мне нравятся стандартные термины, если бы вы знали насколько старое слово domain в английском вы бы очень, очень сильно удивились.
        • 0
          Вы о чем?
          • +1
            О том, что я тюню терминологию скрама и аджайла под наши реалии.
    • +1
      А я бы стал.
  • +1
    А в чем тогда плюсы работать у вас?
    • 0
      Мы никогда не наказываем деньгами. За все переработки даем отгулы. Любое «наказание» провинившемуся сотруднику, заключается в профессиональном росте самого сотрудника.
      • 0
        Ну и основные плюсы:

        1) Мы делаем сложные и интересные проекты. Беремся за то, отчего отказываются многие другие компании, ввиду сложности, сроков и тд.

        2) Мы заботимся о каждом сотруднике, любое наказание служит только для его профессионального роста, и никогда не выглядит как порицание.

        3) Мы делимся опытом, по настоящему, люди у нас растут бешенными темпами, мы не держим парашютистов, тех кто не справляется увольняем. Каждый знает что человек с кем он будет работать в команде профессионал.

        4) Люди знают куда и как расти. Как профессионально так и материально, мы приветствуем тех, кто строит карьеру.

        5) Когда люди перерастают нашу компанию, мы отпускаем их, и у нас их с радостью берут в Гугл, Майкрософт, крупные европейские компании.

        6) Мы платим конкурентоспособные ЗП, устраиваем постоянные посиделки, кормим сотрудников в офисе.

        7) Мы любим посылать сотрудников в командировки в интересные места, они смотрят мир, работают днем, вечером отдыхают.

        8) Мы всегда защищаем своих сотрудников, в любой ситуации, перед клиентом наш сотрудник прав, внутри компании мы можем устроить «разнос».

        9) Мы любим дерзких разработчиков, дерзкие проекты и дерзкие цели.

        Поэтому к нам и идут. Конечно по пути появляется много балласта, тех кого мы скинули, когда они отлынивали, шантажировали. Они к нам не идут. Но мы и не хотим :)
        • +5
          Ироничный взляд на Ваши пункты из западной европы:
          1) Мы делаем сложные и интересные проекты. Беремся за то, отчего отказываются многие другие компании, ввиду сложности, сроков и тд.
          Добро пожаловать в мир ненормированного рабочего дня, шеф подписал договор, не спросил у нас сколько это делать, теперь пашем без выходных
          2) Мы заботимся о каждом сотруднике, любое наказание служит только для его профессионального роста, и никогда не выглядит как порицание.
          Обучение сотрудников? курсы повышения квалификации? забудьте! либо учись дома либо ты балласт со всеми вытекающими
          3) Мы делимся опытом, по настоящему, люди у нас растут бешенными темпами, мы не держим парашютистов, тех кто не справляется увольняем. Каждый знает что человек с кем он будет работать в команде профессионал.
          Спарта! Когда состаритесь мы вас скинем со скалы (да, не только дети, но и Вы)!
          4) Люди знают куда и как расти. Как профессионально так и материально, мы приветствуем тех, кто строит карьеру.
          Мы вас прогоним через цикл унижений в виде домашней работы и отчетов по ней!
          5) Когда люди перерастают нашу компанию, мы отпускаем их, и у нас их с радостью берут в Гугл, Майкрософт, крупные европейские компании.
          Сложно комментировать без реальных примеров когда отпускали тех кто ненужен и когда отпускали тех на кого завязан важный проект в критический момент
          6) Мы платим конкурентоспособные ЗП, устраиваем постоянные посиделки, кормим сотрудников в офисе.
          Сложно комментировать слоган
          8) Мы всегда защищаем своих сотрудников, в любой ситуации, перед клиентом наш сотрудник прав, внутри компании мы можем устроить «разнос».
          Т.е. с американцами и европейцами вы не сотрудничаете? у них подход к таким вопросам совсем другой.
          9) Мы любим дерзких разработчиков, дерзкие проекты и дерзкие цели.
          Отсылка к пункту 1

        • +2
          А если серьезно, то те методы что доказали свою эффективность в данных условиях и тех ресурсках что есть в наличии — лучшие методы. Если Ваши люди восприимчивы к такой дисциплине, если нет безумной текучки, а даже если есть то для тех проектов что выполняются она не страшна — то все делаете правильно, правда опасаюсь что если Вы выйдете за границы Вашего текущего ареала в плане работы то методы придется серьезно и детально трансформировать.
          • 0
            Вы знаете, я работал в 5-7 крупных компаниях. Когда меня «покупали» вместе с командой. Методы срабатывают всегда. Они могут быть не верны, конечно, но уверенность и принципиальность в их насаждении может иногда искупить даже неровности концепции.

            Когда Apple был в полной «ж» со своими подходами и когда PC догнал макинтошевскую архитектуру все думали что надо менять концепцию, но они просто поменяли рынок. Я не люблю apple, но их верность и убежденность в своих подходах мне нравится.
  • +5
    Кстати, из тех людей что я уволил, 70% попросились назад, покаялись и были взяты на работу.

    Каялись, надеюсь, с соблюдением производственных стандартов?
    (...)Таким образом, публичное исповедание учит человека уничижению и смирению, обязывая к поведению, привлекательному для милосердия. Что касается соответствующей одежды и образа жизни, то в это время следует быть одетым в рубище и лежать в пепле, загрязнив тело нечистотами, а дух погрузив в сетование, и с горечью размышлять о своем грехе (...) днем и ночью стенать, плакать и вопиять, (...) повергаться перед пресвитерами, преклонять колена пред возлюбленными Божьими(...)
    • 0
      Ну практически :). Шутка конечно. Покаялись это значит что они признали что были неправы. Там все было очевидно, поэтому строить из себя «диву» и заставлять быть одетыми в рубища было лишним :). Ведущий не вернулся, вернулись те, кого он туда втащил.
    • +2
      Хорошая была бы шутка, если бы не фраза из комментария чуть ниже:

      У нас есть мини правило, если кто то «накосячит», то он встает и громогласно заявляет «я мудак».
  • +5
    «на очередной ретроспективе публично разобрала случай данного разработчика»
    Интересно, после таких вот митингов команда раза в 2 меньше становится? Или еще меньше?

    Публичная порка это откуда-то из времен Инквизиции. Публично надо хвалить, а разбираться — один на один. А с таким подходом, я бы ожидал, что инициативы, исходящей от команды, или уже нет, или скоро не будет. Накосячил?! -> На костер!

    • +1
      Вообще не становится меньше. Наоборот больше. Мы не держим тех, кто боится признавать свои ошибки и расти от этого. У нас есть правило «ошибаются все», важно то, как ты справляешься с ошибками. Если ты выслушиваешь мнение своих старших коллег и становишься лучше, круто, ты с нами. Если ты относишься к этому как к «порке», «публичному истязанию» мы тебя увольняем, потому что именно ты в следующую ретроспективу, будешь «истязать» других.

      Формат разбора обычно такой. Есть кейс, скажем Вася, он накосячил там-то и там-то, чтобы исправить этот косяк Сережа и Олег скажем, потратили свое внерабочее время. Вася, ты понимаешь в чем косяк? Да — ок. Нет — объясняем. То что ты ошибся это норм, давай мы тебя научим как не делать этих ошибок дальше. И вот тебе тема для доклада, ты как раз всем другим поможешь разобраться в этой теме. Или без доклада, не важно. Приватно то он уже все услышал от своих товарищей и тимлида. Это фигня. Важно чтобы в будущем избежать таких ошибок, вот тут и нужно публичное обсуждение проблемы, и предотвращение ее в будущем.
      • 0
        Хорошая практика наказания, правильная.
        Жизненный пример — университет. Когда заваливаешься на экзамене несколько раз на одном и том же, в конечном итоге начинаешь в этой теме разбираться лучше всех (ну или в армию служить), что в дальнейшем помогает с другими предметами.
  • 0
    Хорошая статья, все правда. Только плохо отформатирована :)
    Я бы еще дополнил, что нужно помнить, что незаменимых не бывает, и это должно быть понятно не только руководителю, но и остальным сотрудникам. Огромное количество прекрасных людей ищет работу.
    • 0
      Учел
  • +3
    Попытка хабрасуицида №2 опять не увенчалась успехом. Третья будет? :)
    Хотелось бы знать — планируете ли вы расти и выходить
    в другие регионы.
    Какие планы по развитию,
    как вы себе это представляете.
    Да что у вас за бизнес, наконец — а то тезисы говорите,
    а понимание, в рамках какой предметной области они были сформулировали
    у общественности (во всяком случае в моем лице)
    — не появляется.
    • +1
      Будет и третья и дальше. Суицидом заниматься не предполагаю. Статьи это больше обещание себе тратить свободное время на работе на полезные для себя вещи и систематизацию знаний.

      Расти нам пока дальше некуда, в Россию выходить не хочется, так как наши проекты уже требуют значительных административных ресурсов, в силу их масштабов. А в Казахстане и Кыргызстане у нас и так все хорошо :).

      Отдельно от роста, стоит развитие. Вот развиваться есть куда, хочется запустить ИТ Академию, раскачать современные ИТ кадры через местные ВУЗы. Также ожидаем запуск новых электронных проектов.

      Бизнес простой — создание концепции, разработка бизнес кейса, разработка бизнес плана, запуск ИТ проекта, создание ИТ проекта, внедрение ИТ проекта, сопровождение ИТ проекта. И так по кругу. Т.е. наша компания это ИТ компания полного цикла, мы сами придумываем себе занятие :), делаем это, и сопровождаем.
  • +4
    Эталонная оценка, это оценка за сколько конкретную задачу выполнит ваш лучший разработчик. Затем вы определяете что от эталонной оценки может быть отклонение в рамках +-20(30)%.

    У вас действительно настолько высока точность оценки? И действительно производительность разработчиков отличается в рамках 20(30)%?
    Позвольте вам не поверить.

    Если разработчик выпадает за рамки оговоренных пределов, необходимо чтобы команда провела публичное обсуждение проблем, и на очередной ретроспективе публично разобрала случай данного разработчика, и если он виноват, нагрузила его общественными работами, скажем в виде предоставления доклада на тему где он «плавает». При этом доклад готовится строго во вне рабочее время.

    публично… виноват… строго во вне рабочее время…

    Мне хватает тех пендалей, которые мне выдает моя совесть и профессиональная гордость. Я сам себя живьем съем, мне стыдно перед коллегами, если накосячу. Не хватало еще чтобы меня публично порол менеджмент.
    Вы жесткий — ваше право. Ваши разработчики это терпят — это их право. Но, знаете, не хотел бы работать в таких условиях. И подозреваю, что очень многие разработчики — тоже.
    Но, все же, как хорошо, что рынок труда большой.
    • –4
      Рынок труда большой. И я вас уверяю, я бы не мог с вами работать. Совесть и профессиональная гордость она ваша, а люди в команде мои. Как я приводил пример ранее, гордые и совестливые сотрудники, могли уходить во время проекта, а их менее гордые и совестливые коллеги должны были покрывать их «косяки».

      Помимо гордости, совести и тд важен командный дух. У нас есть мини правило, если кто то «накосячит», то он встает и громогласно заявляет «я мудак». Я эту фразу говорю в среднем два-три раза в неделю. Не потому что я плохой работник, а потому что много делаю и значит где-то косячу. Но мои ошибки должны решаться быстро, с помощью других людей и с минимальными последствиями. А еще я должен сделать так, чтобы никто больше эти ошибки не допускал, поэтому я фиксирую это и стараюсь чтобы об этом узнала вся команда.

      Очень долго и скрупулезно мы в команде строили систему, что ошибки это нормально, их нельзя скрывать. Если ты видишь проблему или ошибся, говори сразу, стоимость решения проблемы при ее раннем обнаружении гораздо ниже, чем когда уже ты выпустил продукт. Я знаю гордых разработчиков, которые косячили, не замечали, потому что надеются на свою профессиональную совесть и выпускали говно-код. Потом гордо увольнялись, а толпа профессионалов положив на свою гордость потом допиливала их код.

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

      Я думаю эмоции должны быть вне работы. Пожалуйста не принимайте на свой счет, когда я тут говорю ты, это обобщенно. Возможно, что вы исключение из правил.
      • +1
        То что мы бы не сработались — это понятно, говорю безо всяких эмоций.
        Я немного о другом:

        1) Кажется сомнительным, что можно оценивать и соблюдать сроки по оценкам задач в рамках 20-30%. Кажется сомнительным, что все разработчики не отличаются от лучшего разработчика на 20-30%. В реальности даже простые мелкие задачи могут занять как в 2 раза больше, так и меньше времени.
        Мне видится следующие варианты, когда возможен указанный вами результат попадания в 20-30%:
        а) разработчики втихаря перекидывают время с одних задач на другие, чтобы в среднем вписаться в оценки (или хотя бы чтобы запаздывание было равномерным по всем задачам).
        б) речь идет не об оценки каждой задачи, а об оценке итерации разработки (спринта), которая включает несколько десятков задач и учитывает коэффициент эффективности (velocity)
        в) все ваши задачи типичны и их трудоемкость хорошо известна из опыта.
        Возможно, я что-то упустил. Проясните пожалуйста, как вам удается достигнуть таких результатов при планировании.

        2) Полностью согласен, что самое важно на проекте — команда. Но, в описанном вами же случае, когда от вас ушла команда целиком (и не важно, что они потом почти все вернулись) — команду вы упустили. Прямо как «Федорино Горе». Рассуждения о командном духе, о гордости нехороших разработчиков, о готовности учиться и исправлять ошибки и т.д — это все лишь слова.
        А вот факт ухода команды — это конкретный косяк управления. Просто офигезный косяк. Если руководитель является владельцем — он теряет команду, деньги, в худшем случае — проект и клиентов. Если руководитель работает по найму, то как после потери команды он смог сохранить свое место? (Простите, если чем-то вас задеваю, такой цели нет).

        Честно, мне понравилась ваша статья. Вы жестко описали свою жесткую позицию и жесткий стиль управления. И (по крайней мере у вас) этот стиль — работает и приносит прибыль. С точки зрения бизнеса — замечательно. Вызывает уважение.
        Но с позиции обычного разработчика то, что вы не пугаете людей, а просто их прессуете — понравится не может.

        • 0
          Но с позиции обычного разработчика то, что вы не пугаете людей, а просто их прессуете — понравится не может.

          Сложно судить о том, как это работает на практике, пока сам об этом не узнаешь. Но у меня сложилось впечатление, что автор пытается (и, похоже, успешно) выстроить систему, при которой за хорошее — поощряют, а за плохое — очень корректно говорят о проблеме и просят больше так не делать. Адекватный разработчик после подобных «публичных порок» станет работать лучше, неадекватный будет обижаться и делать хуже. Как правильно заметили, на работе важны профессиональные качества, а не эмоции. Обижаешься — до свидания.

          Альтернативой «публичных порок» на ретроспективах может стать код ревью с объявлением результатов всей команде без указания конкретных провинившихся. Метод хорошо работает опять же для адекватных разработчиков — сами узнают свой код, сами прочитают в чём проблема, самим будет стыдно и больше так делать не будут.

          В управлении пока лучше всего работает принцип кнута и пряника.
        • +1
          1) По поводу сроков вы подняли очень большой пласт проблем. Более подробно я бы хотел осветить этот вопрос в дальнейших статьях. Пока же, ключ к решению проблемы которую вы обозначали это публичное обсуждение проблемы. Важно привить команде философию что ошибаться это не плохо. Если ошибка становится чем-то постыдным вы теряете большой пласт знаний которые можно получить от испытания чего-то нового. Поэтому когда разработчик не попадает в эталонный срок существует несколько моментов:

          1.1 Разработчик не до конца понял задачу, неправильно составил легенду (об этом в следующих статьях), не оценил масштаб. На практике мы просим об этом говорить сразу, как это только становится понятным. В таком случае собирается команда и обсуждает почему была неправильная оценка, и что со всем этим делать. Если 20-30% для данного уровня разработчика слишком много, мы его убираем на некритичные задачи, которые не находятся на «критичном пути», если это была не системная ошибка, а связанная с данным конкретным случаем мы оставляем планку для этого разработчика такую же и подключаем доп. ресурсы.

          1.2 Сложные задачи. Любую задачу можно приблизительно оценить и попасть 20-30% если она понятна и мы уже это делали. Если же задача неизвестна, и есть опасность работы с ней мы создаем черный ящик и на него заводим тикет на исследование, который выполняет наиболее опытный разработчик. После того как черный ящик вскрывается, создаются связанные тикеты, которые выполняют разработчики стараясь попасть в 20-30%

          1.3 Оценивает не один лучший разработчик. Оценивают старшие разработчики, если их оценка стабильно отличается более чем на 20-30% от разработчика, мы стараемся данного разработчика перевести в тестеры или на аналитику. Это относится к разработчикам и старшим разработчикам. Для джуниоров возможно расхождение до 50% но они все сидят на некритичных задачах.

          1.4. Мега важный момент это написание легенд. После того как заказчик (менеджер или кто-то) ставит задачу разработчик обязан написать легенду, в повествовательном стиле. Я буду делать то-то и то-то, так то и так то. Тут я создам черные ящики и буду столько то исследовать. Потом я нарисую такую вот формочку и будет там все так работать. Пишется обычным русским языком, стараясь использовать минимум технических терминов. На написание легенд в итерации выделяется где то 25% от времени итерации. Это время не учитывается в оценки времени. Легенда есть договор между разработчиком и постановщиком задачи, что именно это и должен сделать разработчик и он все правильно понял.

          2) Команда не только на проекте. Команда есть еще в компании. Когда кто-то видит что есть особенные, а есть пахари, это плохо влияет на атмосферу в коллективе. Благодаря ротации я не сильно рисковал когда увольнял команду, и я знал что большинство вернется, так что там риск был минимален. Важнее было научить всех что все равны, и нет людей ровнее.
          • 0
            Спасибо за развернутый ответ о планировании!
          • 0
            «черный ящик» — без оценки? В чём смысл заводить сначала задачу без оценки а потом по её итогам задачу с оценкой?

            Сдаётся мне почти вся реальная работа делается в этих «чёрных ящиках», а когда почти всё готово создаются Ваши любимые 30%-ники.
            • 0
              Смысл в том, что черный ящик нельзя оценить. Можно только дать вайлдгес, который мы и используем, НО не учитываем в итерации как точный срок.
              • 0
                Хорошо, спрошу немно иначе. Каков процент таких задач по количеству и/или по времени?
                • 0
                  % задач где то 2-3% от количества задач, именно просто отдельных тикетов. По времени занимает до 50% емкости разработчика в итерации.

                  Важный момент, черный ящик не вовлекает разработку, только аналитику, и разбив черный ящик на управляемые тикеты мы можем уже планировать итерацию.
                  • 0
                    Примерно то что я и ожидал… Вам не кажется что измерение результативность сотрудников на заранее отобранных (кстати зачем?) задачах, игнорируя реально сложные (и соответственно менее предсказуемые), оставляет в итоге не лучшие кадры?
                    • 0
                      Смотрите, тут важно различать разработчиков и архитекторов. Разработчики это некая «толпа», т.е. основная «масса» сотрудников, которые должны выполнять задачи. Часто не интересные и глупые. При этом они хорошие специалисты и умеют писать достаточно хороший код. Такие люди нужны обязательно, их должно быть где то 80% от общей массы сотрудников. Их мы и оцениваем и даем возможность роста.

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

                      Отличными разработчиками не рождаются, и ими не становятся, ими приходится делать себя, упорно вкалываю. Нельзя быть гениальным человеком и гениальным разработчиком без долгого, нудного и тяжелого саморазвития.
      • +3
        У нас есть мини правило, если кто то «накосячит», то он встает и громогласно заявляет «я мудак»

        Знаете, это ужасно.
        И драться-то с вами бесполезно. Мозги. Подкорка. Я уверен, при таких хозяевах вы, может быть, добьетесь и большего. И хозяева ваши будут богаче наших. Чего никогда у вас не будет — так это самих себя. Потому что, когда ты одеваешь на себя игрушечную ковбойскую шляпу — ты одеваешь ее навсегда. По-другому не бывает. Это только кажется, что выполняя в офисе идиотские приказания, ты на улице или дома становишься человеком. Никогда. Никогда ты им больше не будешь.

        (с) Хроники тестировщика
        • –1
          Вы можете это не говорить. Просто к ошибкам нужно относиться проще.
  • 0
    Скажите пожалуйста, какова вилка в возрасте ваших разработчиков? Каков примерно средний возраст работников?
    • 0
      Вилка ужасная :). От 17 до 41го.
      • 0
        А в среднем? Из «не-старших» и «не-архитекторов»?
        • 0
          18-29

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