04.09.2017 03:26
vryashentsev 243 32300 Источник
За свои 12 лет работы в сфере разработки ПО, мне посчастливилось поработать в команде только два раза. Хотя я сменил порядка десяти мест работы. Но попробовав раз, ем и сейчас… Т.к. я не жадный, и готов своими достижениями делиться с сообществом, то решил я предпринять попытку вывести из равновесия неумных руководителей, которые до сих пор не осознали важность команды, а также тех руководителей, которые профессионально занимаются самообманом — мол, они строят команду, а на деле — тьфу, а не команда.

Контекст данной статьи — разработка своего продукта.

Ваша команда — не команда


  • Если никто ни разу не назвал — директора козлом или PM-а — мёртвым балластом или компанию — сборищем нахлебников — вы не команда. В каждой компании есть проблемы, из-за которых у многих свербит, но если эти “многие” не говорят о проблемах, значит четвёртая промышленная революция пройдет мимо вас. Отсутствие свободного высказывания мнений приводит к принятию проблем как должного и потере критического мышления. Вы вообще ретроспективы проводите? Неееет? Я бы постеснялся назвать вас руководителем.
  • Если вы решаете за сотрудников как им работать — вы не команда. Вы спускаете сверху git flow, список статусов задач, рабочие часы с 9:00 до 18:00? Похоже, вы упрощаете себе жизнь за счет того, что не пытаетесь найти правильное решение в конкретной ситуации? А может быть, чтобы отчитаться перед руководством о переходе на git flow? Оооо… да вы формалист. Только сама команда знает в каких условиях она может работать эффективно и только сама команда знает какие инструменты им нужны для работы. Если вы навязываете ваши правила против воли команды — вы не руководитель.
  • Если ваши сотрудники не знают миссии продукта и/или ближайшей цели — вы не команда. Ваши сотрудники не могут и шага сделать без вас, они просто сидят ровно на попе, пока вы не узнаете об этом и не дадите им крайне точно сформулированную задачу. Ну что же, возможно, ваша сила в микроменеджменте. Шучу, нет такой силы. Пожалуйста, увольтесь. Освободите место для профессионала.
  • Если вы не знаете целей и интересов ваших сотрудников — вы не команда. Вася Пупкин уволился? Не знаете почему? Денег, наверное, где-то больше предложили? Поняаатно. Петя Ласточкин целыми днями смотрит анимешки? Не знаете почему? Может потому что вы ему никуда сдались? Как вы собираетесь мотивировать ваших сотрудников, если не знаете что им нужно? Никак? Ах, вы им ведь зарплату платите, а мотивировать они должны себя сами… ну платите дальше.
  • Если вы боитесь доверять сотрудникам ответственные функции — вы не команда. Да, мы уже поняли, что ваша сила в микроменеджменте. Но кажется, у вас появилась еще одна причина для него. Я вот что думаю — увольте всех и запилите продукт самостоятельно. Ведь чтобы сделать всё правильно — надо делать самому?

На каком этапе провала вы находитесь?


А теперь я помогу вам представить каково же работать в “команде”, руководитель которой собрал в себе все упомянутые выше черты великих полководцев:

  • Усилия сотрудников направлены на то, чтобы прикрыть себе задницу, вместо того, чтобы работать на общее дело.
  • Инициатива? Творчество? Пффф… Я буду сидеть на попе ровно, пока PM не придет и не поставит мне чёткую задачу. Даже если в её формулировке будут проблемы — я никому ничего не скажу, ведь это проблемы PM-а, а не мои.
  • Ответственность. Почему я никому не сообщил о проблемах в постановке задачи? Я не обязан выполнять PM-скую работу. Найдите PM-а, который всегда всё делает правильно и отвалите от меня — я «кодю».
  • Принятие прекрасных решений. Почему я не предусмотрел масштабирование? А надо было?
  • Ребята, у нас форс-мажор, сможете задержаться на два часа, очень нужно? Не хочу. Ваши форс- мажоры — ваши проблемы.
  • Сроки не выполняются. Они уменьшены до предела. Ведь чем сильнее бьешь — тем быстрее пишет код программист.
  • Сроки непредсказуемы т.к. внутреннее качество… А что это?
  • Вы получаете по шапке от своего руководства и бьёте по шапке подчинённых.
  • Смерть уже не кажется наказанием.

Прекрасный мир, в котором вы никогда не будете жить


Я жил в нём, а многие из вас даже не увидят его своими глазами, но я постараюсь вам помочь взглянуть на этот мир моими глазами:

  • Мы не боимся и даже любим высказывать своё мнение. Да, это бывает больно, но боль заставляет нас двигаться вперёд.
  • Мы не молчим о проблемах. Если кто-то попытается замять проблему — мы перестаём его уважать и вполне можем перешагнуть через его голову при решении проблемы.
  • Наши действия подчинены общей цели. Если кончились задачи — мы всегда знаем, что и когда должно быть сделано. Поставим себе задачи сами. Хотя такого, чтобы кончились задачи — не бывает.
  • Общая цель формулируется так, что учитывает цели каждого. Более или менее. Если есть человек, цель которого мешает достижению общей цели — он покидает команду.
  • Руководитель — всего лишь одна из ролей проекта. Его основная задача — создавать условия для работы. Приказы допускаются только в форс-мажорных случаях. А вообще-то нет, не допускаются никогда.
  • Культ качества. Качество даётся бесплатно если не экономить на нём. Поясню: именно плохое внутреннее качество продукта даёт замедление работы и непредсказуемость сроков. Поэтому руководители, которые гонят лошадей — ну вы поняли.
  • Непрерывное развитие. Человек, остановившийся в развитии не нужен в такой команде. Даже чтение статей уже не является залогом вашего успешного существования. Чтение книг уже давно стало обязательным.
  • Ребята, вы опять пришли работать в субботу? А нука пошли отдыхать! А… приказы недопустимы? Ну как вам будет угодно, но постарайтесь не копить усталость.
  • Сроки выполняются всегда.
  • Получать по шапке? За что? Я второй человек после ген. директора, который думает о благе компании. Он ценит это.

Выводы


  • Продукты, которые разрабатываются не командами рано или поздно умрут мучительной смертью. Да, все продукты рано или поздно умирают, но часть из них — естественной смертью, а часть — от болезней.
  • В команде работать приятно. Меньше сил тратится на переживания, больше — на работу.
  • Команда — это неисчерпаемый источник сил и мотивации.
  • Человек, работающий в команде, постоянно растёт в стоимости. Работа в команде выгодна каждому участнику.
  • Учись или проиграешь.

Спустите пар


В статье описаны идеальные случаи, которых в реальном мире не бывает. Но я таки утверждаю, что работал в почти идеальной команде. А одну очень неплохую команду построил своими руками (и головой).

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

ПС: каюсь, я тоже однажды создал “команду”, практически, идеально отвратительную. Я описал часть своего отрицательного опыта в своей первой статье.

На почитать


  • Человеческий фактор: успешные проекты и команды. Том Демарко, Тимоти Листер.
    Данная книга дала понять, что основная задача руководителя — создавать условия труда, а не раздавать команды.
  • Идеальный программист. Роберт Мартин.
    Дядя Боб очень категоричен в определении понятия ответственности, но разве можно не верить ему?
  • Помогите им вырасти или смотрите как они уходят. Беверли Кей, Джулия Джулиони.
    Эта книга помогла мне держать фокус на мотивации.
  • Scrum и XP: заметки с передовой. Хенрик Книберг.
    Очень краткая и практичная книга, она рассказала, как конкретно можно строить agile.
  • Impact mapping. Gojko Adzic (не представляю как по-русски написать).
    Тут я почерпнул важность целей, а также получил информацию о том, как их можно использовать.
  • Крайне рекомендую обратить внимание на проект Аристотель — исследование Google об эффективных командах.

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


  1. acyp
    04.09.2017 07:06
    #10396832

    Интересный обзор, со многим согласен. Но чем git flow не угодил не совсем понятно.


    1. vryashentsev Автор
      04.09.2017 07:09
      #10396834
      +9

      С git flow всё в порядке, а вот насильное внедрение чего бы то ни было — не порядок.


      1. acyp
        04.09.2017 07:17
        #10396840

        Часто на проектах внедрения (1с) сталкивался с неприятием пользователей предлагаемой системы работы. К окончанию проекта делали повторный замер производительности (количества операций, оформленных документов, обслуженных посетителей, etc...). Чаще было в пользу системы и неприятие оказывалось деконструктивным.
        Понятно, что творческий коллектив — это несколько иное (наверное), но это означает, что команда у нас есть :). Мы все приходим к 8-30 (начинаем работать в 9), уходим в 18-30 и позднее (офф — 18), видимо осознавая ценность дисциплины. И работа в выходные — не палочная, а по велению души.
        Спасибо, что еще раз подтвердил, что у нас все относительно благополучно.


        1. vryashentsev Автор
          04.09.2017 07:20
          #10396842
          +3

          осознавая

          Вот! Это главное слово для строительства любой рабочей системы.


        1. 0xd34df00d
          06.09.2017 07:21
          #10401068
          +3

          Мы все приходим к 8-30 (начинаем работать в 9), уходим в 18-30 и позднее (офф — 18), видимо осознавая ценность дисциплины. И работа в выходные — не палочная, а по велению души.

          Включаете ли вы чтение статей-книг в эту самую работу? Свои хобби-проекты, в которых можно что-то новое отточить и попробовать?


          1. acyp
            06.09.2017 11:46
            #10401548
            +1

            Не знаю как коллеги, я часто на работе читаю статьи и книги. Тут сразу можно попробовать. Да и комфортнее, сдвоенный монитор против одиночного дома, плюс дома — это все таки близкие, которым тоже надо внимание уделить.
            Хобби-проекты — да, причем пилим с коллегами. И были случаи, когда такой х-п (точнее полученные на нем навыки) дал возможность выиграть тендер.


            1. 0xd34df00d
              06.09.2017 20:21
              #10403144
              +1

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


      1. dklein
        04.09.2017 08:43
        #10396880
        +2

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


        1. vryashentsev Автор
          04.09.2017 08:47
          #10396882
          +1

          Я согласен с тем, что необходимо постоянно что-то менять.


          1. telhin
            04.09.2017 10:22
            #10397008
            +9

            Видел интересную мысль на хабре по этому поводу. Своими словами могу сформулировать так: Правило одного нового. Команда делает или новый проект на известном стеке технологий, или команда делает типовой проект на новом стеке технологий.


            1. khim
              04.09.2017 22:31
              #10398234
              +1

              Команда делает или новый проект на известном стеке технологий, или команда делает типовой проект на новом стеке технологий.
              Это не всегда удаётся. Но даже в этом случае полезно разделить команду на две — одна будет пилить новые технологии (если старые по каким-то причинам не подходят), другая — новый проект на старых (но консультируясь иногда с первой командой, чтобы в момент, когда новые технологии будут готовы не пришлось всё выкинуть к чертям собачьим).


            1. franzose
              05.09.2017 02:51
              #10398384
              +3

              Зависит от людей. Некоторых и пинать не надо, а другие только по указивке сверху шевельнутся освоить что-то новое, соответственно, если указивок нет, то и развития нет.


      1. acmnu
        04.09.2017 09:57
        #10396976
        +2

        С git flow всё в порядке, а вот насильное внедрение чего бы то ни было — не порядок.

        Взгляните со стороны менеджмента. Унификация процессов внутри компании это очень важно: можно легко перекинуть человека с одного проекта на другой и он в разумные сроки начнет давать результат. Во-вторых, упрощается администрирование: появляются шаблоны проектов, системные администраторы и dev ops начинают раворачитьвать рабочее окружение за часы, а не недели.


        Это все чертовски важно. Ваш же подход программистко центричен, если так можно выразиться, а в компании обычно работают не только программисты, но и devops, тестировщики, внедренцы и т.д.


        1. vryashentsev Автор
          04.09.2017 10:05
          #10396986
          +6

          Вы только что убедили команду применить проверенные инструменты. Вот видите, противоречия нет.


      1. Portnov
        04.09.2017 21:07
        #10398134
        +3

        А теперь у вас продукт пишется четырьмя отделами/командами. Одна юзает git flow, другая просто git, третья mercurial, четвётрая svn. Потому что они лучше знают, что им удобнее. А как релиз выпускать… наймём пятую команду, пусть сами решают как собрать один релиз из нескольких реп. Правда, куча времени уйдёт на доведение релиза до рабочего состояния, т.к. компоненты всё время несовместимых версий оказываются. А руководитель продукта… а что руководитель, это не его дело решать в чём команде работать!

        Или нет, давайте пусть весь проект будет в одной системе, пусть вся команда решит. Соберём все четыре отдела (40 человек) в большом митинг-руме и пусть выбирают что им удобнее. Заказчик пусть подождёт окончания холиворов. Руководитель… а что руководитель, это не его дело выбирать в чём команде работать!

        [/sarcasm off]


        1. sshikov
          04.09.2017 21:36
          #10398176

          В большинстве случаев он все равно не выберет...


        1. sergey_prokofiev
          04.09.2017 22:05
          #10398214
          +1

          Затем предлагаю устроить митинги по выбору языка программирования, среды разработки, ишью трекера, системы документации, код конвенций, используемых библиотек-фреймворков, баз данных, архитектуры в конце концов…
          А потом дадим слова тестировщикам — им тоже есть что обсудить и из чего выбрать.


          1. khim
            04.09.2017 22:49
            #10398264
            +5

            Затем предлагаю устроить митинги по выбору языка программирования, среды разработки, ишью трекера, системы документации, код конвенций, используемых библиотек-фреймворков, баз данных, архитектуры в конце концов…
            А потом дадим слова тестировщикам — им тоже есть что обсудить и из чего выбрать.
            Очень хорошее предложение. Без сарказма.

            Есть одно но: слова «а мне нравится» может произносить только и исключительно руководитель (ведь зачем-то он таки нужен?) — а все остальные могут высказывать любые предложения по какому угодно поводу… но с цифрами в руках.

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

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


            1. sergey_prokofiev
              05.09.2017 08:28
              #10398552
              +1

              Оглянитесь вокруг. Народ десятилетиями аргументировано и с цифрами обсуждают проблемы табы&пробелы, виндовс&линукс, .NET&Java&C++&..., микросервисы&монолиты и так далее по списку: любая популярная проблема, не имеющая однозначного ответа просто обречена на бесконечный холивар.
              И тоже самое будет на общем собрании при наличии некоторой критической массы увлеченного народа.


              1. khim
                05.09.2017 13:37
                #10399220
                +1

                Народ десятилетиями аргументировано и с цифрами обсуждают проблемы табы&пробелы, виндовс&линукс, .NET&Java&C++&..., микросервисы&монолиты и так далее по списку
                Не приведёте ссылочек, если народ «аргументировано и с цифрами» что-то там обсуждает?

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

                Если числа есть — то выбирается более выгодный вариант и всё.

                P.S. Под числами я понимаю что-то, что как-то связано с деньгами, которая получит фирма. Так-то в любом споре про табы и пробелы буду два числа: 9 и 32. Но если у вас нет на фирме модулей для которых это важно, то только от того, что 9 < 32 немного, а если есть — то тема перестаёт быть холиварной и становится вполне технической, с единственным ответом.

                И тоже самое будет на общем собрании при наличии некоторой критической массы увлеченного народа.
                Несомненно. Но если они неготовы работать в компании, которая приняла решение, идущее «вразрез» с их желаниями — значит они недостаточно увлечены (или, что то же самое, чрезмерно увлечены мелочами, которые, по большому счёту, не так важны — что то же самое: если вы готовы из-за спора «табы vs пробелы» сорвать релиз… то ясно же, ради чего вы работаете — разве нет?).


                1. sergey_prokofiev
                  05.09.2017 14:23
                  #10399358
                  -1

                  Не приведёте ссылочек, если народ «аргументировано и с цифрами» что-то там обсуждает?

                  У вас забанили и гугл и яндекс? Ок, один раз приведу
                  stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs
                  evelinag.com/blog/2017/06-20-stackoverflow-tabs-spaces-and-salary/#.Wa6Hoa2mNTY
                  Так-то в любом споре про табы и пробелы буду два числа: 9 и 32.

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

                  … то, если верить автору статьи, команда с такими вот разработчиками, сама должна бесконечно долго решать использовать пробелы или табы, а начальство никоим образом не должно команду прессовать.


                  1. khim
                    05.09.2017 17:38
                    #10400014
                    +2

                    У вас забанили и гугл и яндекс? Ок, один раз приведу
                    stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs
                    evelinag.com/blog/2017/06-20-stackoverflow-tabs-spaces-and-salary/#.Wa6Hoa2mNTY
                    Там обсуждается интересный феномен: разработчики, испольщующие Табы в среднем получают меньше денег. Понять — экономи при это деньги бизнес или теряет из ваших «посиделок на кухне» невозможно.

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

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

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

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


                    1. sergey_prokofiev
                      05.09.2017 17:58
                      #10400052
                      -3

                      Тогда что это за числа, если из них нельзя сделать выводы?

                      Базовые числа, от которых надо отталкиваться при принятии решений. Если, к примеру, выбирать между .NET и Java, то есть огромное количество всевозможных бенчмарков, обоснований, экспериментов и так далее в пользу каждого из решений. И иногда нужно волевое решение ответственного человека.
                      но есть больгинство, которое готово на какой-то один вариант — то либо меньшинство соглашается с мнением большинства, либо меньшинство просто уходит

                      А если (почти) поровну, как в случае в САПР на аэробусе? Как вы там описывали, саботаж неизбежен?


                      1. khim
                        05.09.2017 21:31
                        #10400406
                        +1

                        А если (почти) поровну, как в случае в САПР на аэробусе?
                        Там не было «поровну». Там были «новаторы» французы и «консерваторы» немцы.

                        В такой ситуации — нужно было либо добиться консенсуса, либо сделать так, как было сделано, но чётко оговорить, что это сделано под ответственность немцев. А иначе — получаем то, что получаем.


                        1. sergey_prokofiev
                          06.09.2017 10:22
                          #10401338
                          -3

                          Там не было «поровну». Там были «новаторы» французы и «консерваторы» немцы.

                          Ну вот если посчитать первых и других, по головам, то получится «поровну».
                          В такой ситуации — нужно было либо добиться консенсуса, либо сделать так, как было сделано, но чётко оговорить, что это сделано под ответственность немцев

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


                          1. khim
                            06.09.2017 17:37
                            #10402652
                            +1

                            Отличные варианты. Либо жевать сопли месяцами, либо сознательно пойти на факап, который таки случился «сам собой».
                            Это были два единственных реалистичных варианта. Причём второй вариант — вовсе не гарантирует «факапа». Если вы проблему несовместимости двух версий софта не «заметаете под ковёр» и выясняете что кабеля не подходят к конструкции только уже при сборке самолёта, а проводите соответствующие эксперименты и оценки заранее — то вы такого факапа бы не получили.

                            Идеи «поставить на рабочие компы одинаковый софт, организовав тренинги для обучения» канечна ни разу не рассматриваются.
                            Нет, потому что речь идёт о реальной компании с реальными людьми. И ставить «на уши» всю компанию (на самом деле даже несколько независимых компаний!) ради одного проекта без веских причин никто не будет.

                            Я надеюсь вы понимаете, что те же люди, которые разрабатывали A380 принимали участие также и в других проектах? Или вы думаете, что все десятки тысяч инженеров, которые этим занимались были подчинены только ему? Тогда бы там больше 6 миллиардов на одни зарплаты ушло!


            1. 0xd34df00d
              06.09.2017 07:24
              #10401070

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

              Ну давайте поиграем. Предположим, нам надо написать некоторый микросервис. Я выступаю, скажем, за хаскель + snap (как раз на выходных написал, всё очень быстро и типобезопасно), вы — за Go. Или за Python. Или за C#. Или что вашей душе угодно. Какие вы тут цифры будете приводить?


              1. vryashentsev Автор
                06.09.2017 07:29
                #10401078

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

                Вы думаете что не всегда есть цифры, исходя из которых можно принять решение? Тогда вступает в игру авторитет отдельных членов команды.


                1. 0xd34df00d
                  06.09.2017 07:32
                  #10401086
                  +1

                  Хороший подход, и это единственное, что приходит в голову.


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


                  Кроме того, представим себе, что вам надо написать теперь не микросервис, а компилятор. Писать компиляторы на питоне — кровь, боль, кишки и страдание. Писать компиляторы на ML-подобных языках — удовольствие и не-платите-мне-зарплату-я-сам-вам-доплачу. Как вы это выразите в числах?


                  1. vryashentsev Автор
                    06.09.2017 07:37
                    #10401090

                    Но это не стимулирует команду развиваться

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

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


                    1. 0xd34df00d
                      06.09.2017 07:43
                      #10401094
                      +1

                      Реальный случай естественно сложнее и учитывает больше факторов чем «я сказал, а вы сказали».

                      Ну вот мне и интересно, как с таким подходом (цифры вперёд) можно принимать решения в реальных, а не идеальных случаях.


                      Но я полагаю и в случае с написанием компилятора можно найти более полезные цифры.

                      Я лично не представляю, где.


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


                      1. vryashentsev Автор
                        06.09.2017 07:47
                        #10401104

                        Почему нельзя. Прототипирование — хороший инструмент в условиях неопределенности. Кстати, да. Прототип как раз может дать цифры в случае компилятора.


                        1. 0xd34df00d
                          06.09.2017 08:18
                          #10401136
                          +1

                          Потому что на это суммарно ушло дней 30 выходных и праздников. А решать обычно нужно чуть быстрее.


                          1. vryashentsev Автор
                            06.09.2017 08:31
                            #10401146

                            Значит в прототип должно быть меньше функций.
                            И потом 30 дней для проекта рассчитанного на пару лет — не так уж и много, встречал такие прототипы.


                  1. vryashentsev Автор
                    06.09.2017 07:40
                    #10401092

                    Но чтобы наш разговор стал более предметным, обозначьте вашу позицию. Что вы утверждаете?


                    1. 0xd34df00d
                      06.09.2017 07:43
                      #10401098

                      Что не всё заворачивается в цифры. При всей моей любви к математике и формальным рассуждениям, поэтому к сожалению.


                      1. vryashentsev Автор
                        06.09.2017 07:48
                        #10401106

                        Как я чуть выше сказал, голосование — тоже цифры, но не особо точные. Количество довольных разработчиков — тоже цифры. Т.е. считать можно и довольно неформальные показатели.


                        1. 0xd34df00d
                          06.09.2017 08:28
                          #10401142
                          +1

                          Ну, как по мне, это не сильно отличается от обсуждения без цифр, от которого мы пытались уйти.


                          1. vryashentsev Автор
                            06.09.2017 08:53
                            #10401176

                            Пожалуй да, не отличается.


                1. TimTowdy
                  06.09.2017 14:18
                  #10401898

                  Вы думаете что не всегда есть цифры, исходя из которых можно принять решение? Тогда вступает в игру авторитет отдельных членов команды.
                  Цифры есть всегда, но обычно от них не так много толку. Цифры полезны тем, что они объективны, но они работают только когда вы сравниваете одинаковые вещи. Объективно сравнить 2 банана и 3 яблока вы не можете.

                  Допустим вы выбираете между Go, PHP и Python: PHP популярнее, но у вас в команде доминируют Go разработчики, и при этом большая часть софта уже написана на Python.

                  Как посчитать что даст большую прибыль компании, PHP, Go или Python? Кстати, на какую прибыль мы будем ориентироваться, долгосрочную или краткосрочную? (и это даже не выбор из двух вариантов, это непрерывная величина)

                  Как вы сами сказали, в игру будет вступать авторитет отдельных членов команды. Это будет происходить всегда, и в этом случае польза от цифр сильно падает, т.к. свою основную роль (объективность) они уже не выполняют. Максимум что они вам дают — возможность предостеречься от глупых ошибок, например писать на Brainfuck, потому что «авторитет» так захотел.


        1. khim
          04.09.2017 22:42
          #10398250
          +2

          А теперь у вас продукт пишется четырьмя отделами/командами. Одна юзает git flow, другая просто git, третья mercurial, четвётрая svn. Потому что они лучше знают, что им удобнее.
          Интересно, что вы почти точно описали что у нас происходило лет так примерно 5 назад. Правда gitflow у нас не было, но svn и mercurial — были. И людям, которые предлагали это всё заменить на git пришлось долгое время поддерживать альтернативных клиентов и обьяснять все преимущества git'а в мире, где центральные сервера используют mercurial и SVN.

          И они с этим справились! Хотя это и потребовало много времени, но зато все шероховатости были убраны до того, как все перешли на git — а если бы git-flow «внедрили указом», то все так бы и проклинали его годами вспомниная как клёво было когда их никто не заставлял «этим ужасом» пользоваться.


          1. avost
            04.09.2017 23:34
            #10398306

            преимущества git'а в мире, где центральные сервера используют mercurial и SVN.

            А в чём преимущество гита перед меркуриалом?


            1. khim
              04.09.2017 23:39
              #10398310
              +4

              В скорости. Если у вас «срез» проекта занимает не один десяток гигабайт, то элементарные операции с mercurial'ом начинают занимат ощутимое время. И оказывается что за то, чтобы операции происходили за секунды, а не за минуты люди готовы простить git'у очень и очень многое.


            1. tsul
              05.09.2017 03:24
              #10398390
              +2

              Я в своё время отказался от hg, т.к. тот не умел русские имена файлов под Windows. На заплатку FixUtf8 они забили… Похоже, воз и ныне там: WindowsUTF8Plan не обновлялся с середины 2014-го.


          1. sergey_prokofiev
            05.09.2017 08:34
            #10398566
            -3

            И они с этим справились! Хотя это и потребовало много времени, но зато все шероховатости были убраны

            Я переведу на понятный: наш заказчик заплатил за неспешное образование и душевные переживания нашей команды.


            1. Hardcoin
              05.09.2017 11:23
              #10398840
              +6

              Или так или платить за снижение мотивации работать. Программисту норму "15 гаек в час" не поставишь. Вроде работает, результат есть, а то, что его на 20% меньше, потому что его все бесит — не угадаешь


              1. sergey_prokofiev
                05.09.2017 12:27
                #10399036
                -5

                Еще как поставишь и KPI есть во всех крупных компаниях. Как только количество инженеров в проекте начинает измеряться десятками — моментально появляется статистика и соотвественно инструменты для измерения производительности каждого программиста.


                1. khim
                  05.09.2017 13:39
                  #10399230
                  +4

                  Там и появляется «китайский» и «индусский» код. Я вас уверяю — фирмы, пишущие в 10'000 строк то, что можно написать в 100 не получают более дешёвого и качественного продукта — это иллюзия.


                  1. sergey_prokofiev
                    05.09.2017 14:36
                    #10399406
                    -3

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


                    1. mayorovp
                      05.09.2017 14:41
                      #10399420
                      +1

                      Вот тут вы говорили про цену кода:


                      Я переведу на понятный: наш заказчик заплатил за неспешное образование и душевные переживания нашей команды.


                      1. sergey_prokofiev
                        05.09.2017 14:56
                        #10399468
                        -3

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


                        1. mayorovp
                          05.09.2017 15:12
                          #10399538
                          +4

                          Это вы не поняли, что грамотный менеджмент следит за мотивацией сотрудников, а не за KPI.


                          1. sergey_prokofiev
                            05.09.2017 15:18
                            #10399558
                            -2

                            Вы все таки не понимаете, что мотивация сотрудников — это один из KPI.


                            1. mayorovp
                              05.09.2017 15:19
                              #10399564
                              +2

                              И как же ее в таком случае измеряют? :-)


                              1. sergey_prokofiev
                                05.09.2017 15:27
                                #10399582

                                валом способов. Навскидку:
                                — кол-во эскалаций от сотрудников на менеджмент
                                — кол-во уволившихся-ротированных сотрудников
                                — рост зп(внезапно, если не сильно требуют, то низкий рост вместе с низкой ротацией — все довольны)
                                — удовлетворенность работой(опросники)
                                — «360 degree review»
                                Но это только вершина айсберга :)


                                1. mayorovp
                                  05.09.2017 15:33
                                  #10399602
                                  +1

                                  Допустим, ваши KPI работают и выявляют что программисты халтурят. Каковы действия идеального менеджера?


                                  После этих действий программисты все еще халтурят. Каковы действия идеального менеджера?


                                  После этих действий программисты научились обходить KPI, показывая хорошую мотивацию в опросах. Но проект так и не ускорился. Каковы действия идеального менеджера?


                                  1. sergey_prokofiev
                                    05.09.2017 15:41
                                    #10399644
                                    -4

                                    После этих действий программисты научились обходить KPI, показывая хорошую мотивацию в опросах.

                                    вы даже не понимаете, про какие KPI говориться в этом контексте.
                                    Каковы действия идеального менеджера?

                                    42
                                    Именно такое у вас понимание предмета, извините дальше не вижу смысла в дискуссии.


                                    1. mayorovp
                                      05.09.2017 15:52
                                      #10399692
                                      +2

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


                                1. DistortNeo
                                  05.09.2017 15:46
                                  #10399668
                                  -1

                                  Всё вышеперечисленное имеет отношение к качеству менеджмента, а не KPI сотрудников.


                                  1. sergey_prokofiev
                                    05.09.2017 15:48
                                    #10399678
                                    +1

                                    Безусловно, именно это я и написал выше по треду. Мы обсуждали удовлетворенность сотрудников, если что.


                                    1. 0xd34df00d
                                      06.09.2017 07:30
                                      #10401080
                                      +1

                                      — Программисту норму "15 гаек в час" не поставишь.
                                      — Еще как поставишь и KPI есть во всех крупных компаниях.
                                      — …
                                      — …
                                      — Всё вышеперечисленное имеет отношение к качеству менеджмента, а не KPI сотрудников.
                                      — Безусловно, именно это я и написал выше по треду.


                                      Норм диалог.


                                1. 0xd34df00d
                                  06.09.2017 07:28
                                  #10401074
                                  +1

                                  кол-во эскалаций от сотрудников на менеджмент

                                  Я, может, менеджера моего менеджера вообще один раз видел. Откуда мне знать, он нормальный чувак, или они с моим манагером кореша, и он просто моему прямому менеджеру мою жалобу расскажет за кружкой пива/клюшкой гольфа?


                                  кол-во уволившихся-ротированных сотрудников

                                  Отличный KPI для данного конкретного уволившегося сотрудника. А главное — вовремя!


                                  рост зп(внезапно, если не сильно требуют, то низкий рост вместе с низкой ротацией — все довольны)

                                  Опять какая-то агрегация по всем сотрудникам. Вы менеджеров оцениваете или самих программистов?


                                  удовлетворенность работой(опросники)

                                  «В этом месте всё протухло, никакие опросники не помогут, напишу, что всё хорошо, авось поставят плюсик в карму за лояльность и хотя б зарплату повысят.»
                                  Ну это в лучшем (или худшем, как смотреть) случае.


                                  «360 degree review»

                                  См. п. 1.


                                  1. sergey_prokofiev
                                    06.09.2017 10:28
                                    #10401360
                                    -1

                                    Это все интересно, но вырвано из контекста. Я его напомню. Диалог идет о том, как измерить мотивацию сотрудников.
                                    А теперь 2 простых вопроса.
                                    1. Является ли «моя мотивация» KPI сотрудника?
                                    2. Является ли «мотивация подчиненных» KPI менеджера?


                                    1. 0xd34df00d
                                      06.09.2017 20:25
                                      #10403152

                                      Так как вы в итоге снаружи оцениваете мотивацию сотрудника по этим KPI?


                                      1. sergey_prokofiev
                                        06.09.2017 20:32
                                        #10403176

                                        Вы так и не поняли. Оценивается менеджер, который смог(или нет) выстроить эффективный процесс.


                                        1. mayorovp
                                          07.09.2017 08:42
                                          #10403834

                                          "Оценивается менеджер" — это уже более реалистичное применение KPI. Но в таком случае остается открытым вопрос что делать этому менеджеру.


                                          1. sergey_prokofiev
                                            07.09.2017 12:54
                                            #10404498
                                            -1

                                            Но в таком случае остается открытым вопрос что делать этому менеджеру.

                                            Ну я даже не знаю, например забить в гугле фразу «управление персоналом»…


        1. vryashentsev Автор
          05.09.2017 04:28
          #10398424
          +4

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


          1. shurutov
            05.09.2017 16:41
            #10399828
            -2

            Потому что "команда решает, как ей работать" тождественно равно "бардак". Не всегда полный, но бардак гарантированный. Имею как жизненных (до ВУЗ-а), так и профессиональных примеров, когда команда "решала". Все (ВСЕ!) эти примерыр заканчивались плачевно, в лучшем случае — приглашением нового руководителя. Решатели плакали крокодильими слезами в таком случае. Есть примеров, когда команда дорешивалась до ликвидации компании, как самостоятельного лица (либо конкуренты покупали, либо банкротство, либо ещё что-нибудь такое "весёлое").
            Решает ВСЕГДА руководитель. Он же и отвечает за принятые решения перед вышестоящим руководством и прочими инвесторами. И именно поэтому у руководителя з/п выше, чем у рядовых сотрудников. Члены же команды имеет право, а у хорошего руководителя, обязаны, сформулировать и предложить пожелания/требования к средствам и способам совместной работы. А руководитель, в свою очередь, обязан прислушаться к мнению своих подчинённых и выбрать наиболее соответствующие целям и задачам средства и способы.
            А идеальным является руководитель, у которого в подчинении есть товарищи, у которых в договоре прописано разрешение публично объяснять руководителю глубину его некомпетентности не выбирая выражений. Я, правда, таких не встречал, к своему великому сожалению. :(


            1. TimTowdy
              05.09.2017 17:58
              #10400048
              +4

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

              Есть примеров, когда команда дорешивалась до ликвидации компании
              А примеров когда руководитель доводил до той же самой ликвидации вы не видели? Точно также есть примеры, когда компании с плоской структурой были вполне себе успешны.

              Вы построили себе неопровержимую теорию — всегда должен быть авторитарный руководитель. Если это работает — теория хорошая. Если нет — все равно теория хорошая, просто руководитель был неправильный.

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

              Кто-то пострадал от «поэтов» в программировании, и пытается превратить его в армию, а кто-то наоборот, пострадал от диктаторов и пытается дать всем полную свободу. Советую обоим расширить свои взгляды. IT — это не армия, и не поэзия, оно где-то посередине.


              1. Drac013
                06.09.2017 15:27
                #10402162

                беда в том, что идеальных диктаторов не бывает

                Просто небольшая заметка: пример Сингапура в этом плане довольно интересен.


                1. DistortNeo
                  06.09.2017 15:33
                  #10402184

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


                  1. sergey_prokofiev
                    06.09.2017 19:14
                    #10402966
                    +1

                    Но «идеальные» диктаторы таки бывают и они далеко не редкость. Но у всех одна проблема — преемники и тут диктатура дает сбой в 9 случаях из 10(Октавиана Августа выносим за скобки — это было мегакруто :) )


            1. franzose
              06.09.2017 00:56
              #10400824

              Если решает всё и всегда руководитель (интересно, а что, по-вашему, он решает?), есть риск того, что ответственность и качество работы в команде будет снижаться и снижаться. Т.к. всё, что останется делать разработчикам, — выполнять указания сверху.


            1. vryashentsev Автор
              06.09.2017 05:05
              #10400992
              +1

              Если вы чего-то не видели значит этого нет? Ну так я видел команду, которая решала в том числе какие фичи надо запилить для того чтобы бизнесу было хорошо. И бизнес соглашался — потому что предложения были обоснованы. Так же как и команда принимала обоснованные решения бизнеса. И никакого бардака.


    1. aquamakc
      04.09.2017 10:02
      #10396980
      +1

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


      1. acmnu
        04.09.2017 11:04
        #10397064
        +5

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


        1. aquamakc
          04.09.2017 11:08
          #10397072
          +1

          Одно дело, когда врождённое любопытство и перфекционизм разработчика толкает на переписывание готового кода. Другое, когда сверху спускается необоснованное распоряжение из-за которого чуть ли не вся проделанная работа идёт псу под хвост. Что далеко ходить за примером. Проект, несколько лет работающих на MySql было приказано в сжатые сроки перевести на Postgre. Почему? Да просто один управленец прочитал где-то, что мускуль нынче не модно. И чёткие пацанчики поголовно используют только Postgre. Это ещё хорошо, что NoSql пока ещё не знаком этим товарищам.


          1. acmnu
            04.09.2017 11:46
            #10397156

            Одно дело, когда врождённое любопытство и перфекционизм разработчика толкает на переписывание готового кода. Другое, когда сверху спускается необоснованное распоряжение из-за которого чуть ли не вся проделанная работа идёт псу под хвост.

            Я все же думаю это одно и то же. Переписывание кода на новый фреймворк тоже пускает работу коту под хвост.


            1. aquamakc
              04.09.2017 11:51
              #10397170
              +1

              Как правило, инициатива разработчика обоснована и направлена на реализацию конкретных целей, которые призваны улучшить продукт. Тут я не учитываю действия разработчиков «не от мира сего», которые экспериментируют в продакшине.
              Зачастую действия менеджеров, а в частности приведённый выше пример направлен исключительно на ИБД для начальства. А для проекта это сродни саботажу.


              1. acmnu
                04.09.2017 13:43
                #10397434
                +1

                Как правило, инициатива разработчика обоснована и направлена на реализацию конкретных целей, которые призваны улучшить продукт.

                Это в идеальном мире. В нем же и манагеры хорошие вещи делают. Чаще всего на новый фреймворк переходя по принципу "все фигня, кроме пчел".


                1. aquamakc
                  04.09.2017 13:45
                  #10397440

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


            1. aquamakc
              04.09.2017 11:59
              #10397190

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


              1. acmnu
                04.09.2017 13:46
                #10397442

                Я не против вашей идеи, но вы плохих менеджеров-карьеристов почему-то сравниваете с хорошими программистами. Естественно такое сравнение не в пользу менеджеров.


                1. vryashentsev Автор
                  04.09.2017 13:53
                  #10397454
                  +1

                  Кстати, есть забавное наблюдение. Плохой менеджер или плохой программист может стать хорошим, при изменении контекста. Т.е. плохой/хороший является качеством не только самого человека.

                  И еще интересное наблюдение. Комплекты в diablo 2. Надел одну вещь — просто вещь. Надел вторую — получил +20 к урону молнией и сопротивление от ядов. Качества каждого человека в команде это его личные качества + влияние команды.


                  1. questor
                    04.09.2017 22:48
                    #10398260
                    +1

                    Это называется синергетический эффект: энергия системы больше суммы энергий всех входящих в систему частей.


                    1. vryashentsev Автор
                      05.09.2017 04:29
                      #10398426

                      Слышал о таком )


        1. DistortNeo
          04.09.2017 15:54
          #10397658
          +2

          Надо соблюдать баланс. Если программист не будет постоянно изучать новые технологии и расширять кругозор, есть риск остановки карьерного роста. А лучший способ изучить технологию — сделать что-нибудь с её использованием. А если ещё и за деньги работодателя, то вообще прекрасно.


          1. kuznetsovin
            05.09.2017 06:54
            #10398478
            -1

            Я стесняюсь спросить, а вы когда нанимаете кого-то на работу (допустим сантехник, электрик, доктор...) наверное тоже не против того, чтобы они попробовали что-то новое за ваш счёт?


            1. vryashentsev Автор
              05.09.2017 07:07
              #10398486
              +1

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

              Кстати, неверная аналогия у вас. Сантехнику за «что-то новое» платит компания, в которой он работает, а не конечный заказчик. Если сантехник работает сам на себя, то и платит за «что-то новое» он сам. Так же как и разработчики-фрилансеры.


              1. General_Failure
                06.09.2017 07:43
                #10401096

                Наверное скапитаню, но всё-таки заказчик всегда платит и за услуги, и за «что-то новое»
                Хоть сантехнику на зарплате, хоть фрилансеру
                Только это происходит неявно — никому и в голову не придёт сказать клиенту «я тут решил поэкспериментировать за ваш счёт, гоните бабки» (если, конечно, это не учёные)
                Просто расходы на развитие в виде обучения и экспериментов включены в счета за работу и раскиданы по всем клиентам


                1. vryashentsev Автор
                  06.09.2017 07:44
                  #10401102

                  Естественно, деньги в итоге идут от заказчика. Но это не значит что стоимость работ увеличится, если исполнитель экспериментирует. Исполнитель может экспериментировать для того чтобы стоимость его работа не упала со временем.

                  В общем, я согласен, но хотел окрас факта сделать другим.


            1. DistortNeo
              06.09.2017 22:11
              #10403402
              +2

              В случае сантехников, электриков аналогом является вложение в оборудование и инструменты, в случае докторов — какие-нибудь дополнительные курсы. Ну а программист работает мозгами — мозги и нужно развивать.

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

              > наверное тоже не против того, чтобы они попробовали что-то новое за ваш счёт?

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


        1. Hardcoin
          05.09.2017 11:25
          #10398854
          +1

          Значит текущий вызывает много боли и страдания. Либо потому что старый и кривой, либо потому что программист его не знает или вообще обладает низкой квалификацией. Главное отличить одно от другого


    1. DrPass
      04.09.2017 14:58
      #10397568
      +3

      А я наоборот, не согласен. Автор рассматривает команду как группу единомышленников. А это не всегда так. В общем случае команда — это коллектив, где каждый знает свои функции и выполняет их. Этого можно успешно достичь разными способами, и дружеским пониманием, и административным управлением. И в обоих случаях ключевую роль играет не сам способ, а люди. Если они профессионально делают своё дело, команда будет работать. Если нет, то не будет.


      1. franzose
        05.09.2017 03:42
        #10398406
        +2

        Автор рассматривает команду как группу единомышленников.

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


  1. DexterHD
    04.09.2017 09:25
    #10396914
    +2

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

    Инициатива? Творчество? Пффф… Я буду сидеть на попе ровно, пока PM не придет и не поставит мне чёткую задачу. Даже если в её формулировке будут проблемы — я никому ничего не скажу, ведь это проблемы PM-а, а не мои.

    Вот это качество у 80% программистов идет из коробки. «Я программист, мое дело код писать, а дальше трава не расти. Закоммитил, работа выполнена...»


    1. vryashentsev Автор
      04.09.2017 09:29
      #10396918
      +3

      Прикол в том, что когда даже не совсем подходящие кадры приходят в слаженную команду — они принимают правила игры и вливаются.


      1. mayorovp
        04.09.2017 12:30
        #10397246
        +2

        Но только если они проходят в уже слаженную команду. С нуля такой фокус не провернуть.


        1. vryashentsev Автор
          04.09.2017 12:44
          #10397272
          +3

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


          1. mayorovp
            05.09.2017 15:27
            #10399580

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


            1. sergey_prokofiev
              05.09.2017 15:35
              #10399610
              -3

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


              1. franzose
                06.09.2017 02:31
                #10400922

                Ну согласитесь, что если программистами будет управлять SMM-щик, дизайнер или менеджер по рекламе, это неправильно, т.к. он не разбирается в специфике?


                1. khim
                  06.09.2017 03:17
                  #10400946

                  От человека зависит больше, чем от его профессии. Когда мне говорят что IT'шниками должен управлять только IT'шник я всегда вспоминаю Луи Герстнера — «человека, который спас IBM». Пришедший в IBM из RJR Nabisco, которая занималась расфасовкой продуктов (sic!) — а потом вспоминаю про бесчисленных «финансовых гениев», которые сменили «необученных профессионалов» и в результате ввели свою компанию в убытки. Хрестоматийный пример — это, конечно, Стивен Элоп, уничтовший на корню лидера рынка.


                  1. sergey_prokofiev
                    06.09.2017 10:40
                    #10401384
                    -3

                    Хрестоматийный пример — это, конечно, Стивен Элоп, уничтовший на корню лидера рынка.

                    О хосподи, хрестоматийный пример — ваша безграмотность.


                    1. khim
                      06.09.2017 17:02
                      #10402502
                      +3

                      А что я должен был прочитать по ссылке, интересно? Ключевой момент, что ли:

                      Я специально не буду рассматривать другие аспекты деятельности Элопа, такие как ранние обещания продуктов на WP, закрытия фабрик и т.д. Это и без меня много раз было обсосано и нового ничего я тут не скажу.
                      Или другой, несомненно также вполне разумный, тезис:
                      С бюрократией и бизнес процессами, имеющимися на 2010 год, Нокиа не спас бы ни Андроид, ни половина населения Бангалора, пишущих на Qt под MeeGo.


                      Вина Элопа даже не в том, что он угробил Нокиа, а в том, что все его решения имели смысл только в разрере «да, мы уничтожим Нокиа, но спасём Microsoft» (чего, в общем, сделать тоже не удалось — мобильное направление Microsoft потерял).

                      Эта статья была бы черезвычайно ценна, полезна и, действительно, могла бы многое перевернуть в восприятии мира, если бы Элоп достиг таких же результатов, что и Герстнер (проблемы IBM и Nokia были, во многом, схожи). Однако случилось то, что случилось: подразделение, занимавшееся смартфонами, не имевшее до прихода Элопа ни одного убыточного квартала после реорганизации ни разу не принесло прибыли. До самого конца.

                      Плоблема в том, что Элопа, фактически, наняли для того, чтобы он аккуратно изменил стиль разработки и урезал бюрократию — как это сделал Луи. А он, вместо этого, решил всё «до основания разрушить» и… остаться у разбитого корыта. Для этого много ума не нужно, знаете ли.


                1. sergey_prokofiev
                  06.09.2017 10:34
                  #10401370
                  +1

                  Согласен. Каждый должен заниматься своим делом. Управление проектами — это специальность, которой 5 лет учат в вузе(в пост советских — плохо учат), а не тягание квадратиков в жире, как многие думают и как зачастую это бывает в реальной жизне, увы.
                  Специфика безусловно влияет(причем обратно пропорционально масштабу проекта), но не более чем понимание предметной области программистом: хорошо бы если бы отельер с 20 годами опыта переквалифицировался и напедалил booking.com, он то ситуацию изнутри знает. Но в реальности оно бывает немного не так :)


            1. vryashentsev Автор
              05.09.2017 16:43
              #10399832
              +2

              Не обязательно программистом. Может быть аналитиком или тестеровщиком. Вариантов масса.


              1. franzose
                06.09.2017 02:33
                #10400924

                Т.е. он всё равно так или иначе должен быть айтишником)


                1. vryashentsev Автор
                  06.09.2017 05:52
                  #10401006

                  Я не могу этого утверждать. Бизнес аналитик еще может быть. Или эксперт из предметной области. Заказчик, в конце концов.


                  1. mayorovp
                    06.09.2017 07:01
                    #10401048

                    Аналитик, эксперт предметной области или заказчик не сможет обучить команду пользоваться тем же гитом.


                    1. vryashentsev Автор
                      06.09.2017 07:04
                      #10401052

                      Руководитель не должен да и просто не может быть самым опытным в каждом аспекте производства ПО.

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


                      1. mayorovp
                        06.09.2017 10:09
                        #10401306

                        Ну и как команда примет наиболее удобный инструмент управления версиями если половина из них не знает что такое управление версиями, а другая половина поровну делится на фанатов git, mercurial, subversion, старого tfs, cvs и visual source safe?


                        Напомню, по условию в "команде" собрались случайные люди.


                        1. vryashentsev Автор
                          06.09.2017 10:41
                          #10401390

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


                          1. mayorovp
                            06.09.2017 11:37
                            #10401520

                            Напомню с чего началось обсуждение:


                            Но только если они проходят в уже слаженную команду. С нуля такой фокус не провернуть.

                            Откуда вы возьмете авторитетов в случайно собранной из случайных людей "команде"?


                            1. vryashentsev Автор
                              06.09.2017 12:14
                              #10401634

                              Не надо случайным образом собирать команды :)
                              Это серьезный труд и внимание ему надо уделять на старте — всё, без остатка.
                              К тому же команды формируются не щелчком пальцев, а в течении продолжительного времени.


                              1. mayorovp
                                06.09.2017 12:23
                                #10401662

                                Тогда о чем вы спорите?


                                1. vryashentsev Автор
                                  06.09.2017 12:31
                                  #10401672

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

                                  Хотя надо, конечно, отменить, что я — разбираюсь в производстве ПО.


                              1. sergey_prokofiev
                                06.09.2017 13:44
                                #10401814

                                К тому же команды формируются не щелчком пальцев, а в течении продолжительного времени.

                                В идеальном мире возможно.


    1. kabal375
      04.09.2017 10:59
      #10397056

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


    1. franzose
      05.09.2017 03:46
      #10398408

      Получается, что это нежелание брать на себя ответственность, проявлять инициативу в надежде, что её проявит кто-то другой. Ведь тогда все шишки посыпятся на инициатора.


    1. psFitz
      06.09.2017 13:25
      #10401770

      Вот это качество у 80% программистов идет из коробки. «Я программист, мое дело код писать, а дальше трава не расти. Закоммитил, работа выполнена...»
      Такое очень зависит от начальства, работая в предыдущей фирме, где контролировали каждую минуту времени и навязывали технологии, я так себя и вел)
      Сейчас же мне больше повезло с начальством и даже без задач знаю чем себя занять и как улучшить проект


  1. akjoler
    04.09.2017 10:30
    #10397016
    +8

    Какая-то безапелляционная и снисходительная манера подачи… Сколько людей, столько и команд — идеала нет, от слова совсем (советы, типа: «радуйтесь», бесят). В каждой системе есть полезные концепции, есть не очень, есть смешные. Считаете что вам повезло: бывает… хотя, может вам просто хотелось саморекламы?


    1. vryashentsev Автор
      04.09.2017 10:39
      #10397032
      +6

      Рад, что я вас задел. Это была одна из целей. Но давайте по существу.


      1. DexterHD
        04.09.2017 11:00
        #10397058
        +5

        imho, основные тезисы статьи:

        • Я работал в команде, а вы нет
        • Ваша команда — не команда
        • Вы находитесь на этапе провала
        • Вам никогда не жить в прекрасном мире
        • Я молодец ибо работал в команде и построил команду
        • Вот вам пара банальных книг


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


        1. vryashentsev Автор
          04.09.2017 11:24
          #10397098

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

          Тезисы примерно верны, но один вы упустили:

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


        1. sergey_prokofiev
          04.09.2017 11:41
          #10397148
          +5

          Самое забавное то, что судя по введению, аффтар и в командах толком не работал, и с проектами средней продолжительности не сталкивался, не говоря уже о саппорте: за 12 лет опыта аж 2 раза работал в команде и сменил «около 10» мест работы — смена места работы — раз в год.
          Но считает свое мнение достаточно важным и авторитетным для того, чтобы постить стать на хабре.


          1. kabal375
            04.09.2017 13:09
            #10397376
            +1

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


            1. sergey_prokofiev
              04.09.2017 13:13
              #10397386

              Это возможно. Могу разве что попросить топикстартера дать больше инфы о своем опыте: продолжительность проектов, размеры команд, количество команд работающих над одним солюшнем…


              1. vryashentsev Автор
                04.09.2017 13:25
                #10397412
                -2

                Да, скорее всего, сделаю это позже. Пока еще не пришло время.


                1. sergey_prokofiev
                  04.09.2017 14:07
                  #10397484

                  Опять какой то детский сад и тайны мадридского двора.


                  1. vryashentsev Автор
                    04.09.2017 14:14
                    #10397498

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


                    1. sergey_prokofiev
                      04.09.2017 14:24
                      #10397512
                      +5

                      Плохо читаете. Ну да ладно, напишу прямым текстом, мне не жалко.
                      Тезис 1. Программирование есть инженерия.
                      Тезис 2. За крайние 150 лет были наработаны вполне определенные практики управления большими коллективами инженеров, во многом идущие в разрез с опубликованными «рекомендациями».
                      Тезис 3. Все велосипедостроение процессов разработки характеризует состояние менеджмента во многих IT проектах. Впрочем в крупных проектах менеджеры вынуждены ставить нормальные процессы, и у меня складывается отчетливое впечатление, что ваши «рекомендации» идут исключительно от полного непонимания как организовывать работу средней команды в ~50 инженеров(приблизительно половина — девелоперы) на в проекте продолжительностью в пару лет.


                      1. vryashentsev Автор
                        04.09.2017 18:07
                        #10397886
                        +1

                        Перечитал комментарии еще раз. Действительно один комментарий по делу:

                        Сходите в Tata Consulting и расскажите им что не надо решать за сотрудников как им работать

                        Ок, зачту.

                        Программирование есть инженерия.

                        Гениально!

                        За крайние 150 лет были наработаны вполне определенные практики

                        Ого! IT довольно особая область с особыми (избалованными) людьми. По-крайней мере что касается России. И управление в этой области, скажем так, на гребне волны. Так что ваш опыт 150летней давности, похоже, устарел.

                        работу средней команды в ~50

                        Да вы даже определение команды не удосужились посмотреть.
                        Посмотрите определение, а потом рекомендации по размеру. Команды размером 50 человек не бывает.

                        Но вы опять заговорили обо мне. В вашем комментарии нет ни одного утверждения, которое противоречило бы моей позиции, выраженной в статье. Печально.


                        1. sergey_prokofiev
                          04.09.2017 18:24
                          #10397918
                          -3

                          IT довольно особая область с особыми (избалованными) людьми. По-крайней мере что касается России. И управление в этой области, скажем так, на гребне волны.

                          Над гребнем волны, где-то высоко и далеко. Избалованные люди, ценящие возможность выбрать какие задачи, какими инструментами и в какой последовательности они будут делать за счет заказчика — это не профессионалы.
                          Да вы даже определение команды не удосужились посмотреть.
                          Посмотрите определение, а потом рекомендации по размеру. Команды размеров 50 человек не бывает.

                          Над проектирвоанием А-380 трудились тысячи человек и они полностью соответствуют определению «команда» по первой ссылке. Естественно, чтобы управлять такой толпой была выстроена иерархия, как же без нее.
                          В вашем комментарии нет ни одного утверждения, которое противоречило бы моей позиции, выраженной в статье.

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


                          1. khim
                            04.09.2017 23:20
                            #10398290
                            +3

                            Над проектирвоанием А-380 трудились тысячи человек и они полностью соответствуют определению «команда» по первой ссылке. Естественно, чтобы управлять такой толпой была выстроена иерархия, как же без нее.
                            А чем закончилась вся история — знаете или рассказать? Кончилось всё тем, что наступил полный коллапс, самолёт оснастить кабелями не удалось и сотни немецких инженеров пришлось отправлять в командировку во Францию, чтобы они там, на месте, решили-таки, чёрт побери, проблему.

                            Подозреваю что при этом образовалось вполне себе достаточно команд близких к тому, что описано в обсуждаемой статье — и, в конечном счёте, всё успешно разрешилось и самолёт успешно полетел. Убытки примерно в 6 миллиардов — плата за уверенность в том, что «150 лет наработанных практик == залог успеха».


                            1. sergey_prokofiev
                              05.09.2017 08:48
                              #10398576

                              Кончилось всё тем, что наступил полный коллапс, самолёт оснастить кабелями не удалось и сотни немецких инженеров пришлось отправлять в командировку во Францию, чтобы они там, на месте, решили-таки, чёрт побери, проблему.

                              А знаете в чем причина этой проблемы? Я процитирую вики:
                              На начальном этапе производство A380 было осложнено тем, что в каждом самолёте требовалось проложить 530 километров электропроводки. Airbus, в частности, ссылался на сложность прокладки проводки в кабине пилота (100 000 проводов и 40 300 соединительных), на то, что этот отдельный, параллельный проект должен удовлетворять требованиям каждой авиакомпании, на контроль за изменениями в конструкции и контроль за изменениями технической документации[19][20]. Немецкие и испанские заводы Airbus продолжали использование САПР CATIA версии 4, тогда как британские и французские перешли на CATIA версии 5. Это, по крайней мере частично, вызвало некоторые проблемы в области контроля за изменениями в конструкции, так как прокладка алюминиевых электропроводов требовала соблюдения специальных правил, включая использование нестандартных единиц измерения и радиусов

                              Тоесть банально начальник вовремя не помешал работать командам и волевым решением не внедрил одну версию САПРа. Спасибо за такой интересный пример «самоорганизиции команд», я про него сходу запамятовал.
                              Убытки примерно в 6 миллиардов — плата за уверенность в том, что «150 лет наработанных практик == залог успеха».

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


                              1. khim
                                05.09.2017 13:47
                                #10399250
                                +2

                                Тоесть банально начальник вовремя не помешал работать командам и волевым решением не внедрил одну версию САПРа.
                                Вы так говорите, как будто он мог «волевым решением» внедрить одну версию САПРа. Проблема в том, что консервативные немцы отказались переходить на новую версию, а «экспериментаторы» французы — перешли.

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

                                Если бы люди вели себя так, как сервера в кластере: «начальник послал приказ, все его приняли к сведению и через 5 секунд отчитались о выполнении», то ни о каких «командах» мы бы тут не говорили…

                                Но альтернативы иерархичному управлению в масштабе хотя бы 20 человек — нет.
                                Наличие иерархии вовсе не обозначает, что «прямое» общение запрещено и не обозначает, что решения «спускаются сверху» без обсуждения…


                                1. sergey_prokofiev
                                  05.09.2017 14:46
                                  #10399436
                                  -1

                                  Вы так говорите, как будто он мог «волевым решением» внедрить одну версию САПРа. Проблема в том, что консервативные немцы отказались переходить на новую версию, а «экспериментаторы» французы — перешли.

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


                      1. andreylartsev
                        04.09.2017 18:28
                        #10397924
                        +3

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


                        1. sergey_prokofiev
                          04.09.2017 18:34
                          #10397936
                          +1

                          Нормальный процесс — это SDLC процесс позволяющий выдавать предсказуемый результат в оговоренный срок с заранее запланированным уровнем качества, с учетом рисков.
                          А вот

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

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


                          1. andreylartsev
                            04.09.2017 19:21
                            #10398000
                            +7

                            Сергей, нет никакого SDLC который позволяет выдавать предсказуемый результат в оговоренные сроки с заранее запланированным качеством, бюджетом и с учетом рисков.
                            Это Миф. А программирование, точнее разработка ПО, уж извините, далеко не только инженерия.


                            1. sergey_prokofiev
                              04.09.2017 20:23
                              #10398052
                              -5

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

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

                              Не сомневаюсь, что у некоторых это «искусство», «творение» и так далее по шаблону своих братьев по духу, недоучек-гуманитариев. У них, кстате, постоянные проблемы со сроками, догадываешься почему?


                              1. TimTowdy
                                04.09.2017 21:47
                                #10398196
                                +1

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


                                1. sergey_prokofiev
                                  04.09.2017 22:16
                                  #10398226
                                  -1

                                  Дык вся неопределенность выносится на уровень менеджмента. Программист все так же рутинно открывает ишью трекер, читает стори, эстимирует, педалит, перевешивает сторю на тестировщиков. А менеджмент беклога, который становится коротким и непредсказуемым — это уже к лидам и менеджерам, инженерии тут(почти) нет, равно как от инженера не требуется ничего кроме инженерии(возможно — лучшая квалификация чтобы поддерживать codebase во вменяемом состоянии при бардаке с требованиями).


                              1. khim
                                04.09.2017 23:23
                                #10398294
                                +1

                                Сергей, нет никакого SDLC который позволяет выдавать предсказуемый результат в оговоренные сроки с заранее запланированным качеством, бюджетом и с учетом рисков.
                                Есть.
                                Если есть — тогда почему ни A380 ни 787 не полетели в заранее запланированные сроки и их разработка не уложилась в бюджет?

                                A380 вы сами как пример привели, никто вас за язык не тянул.


                                1. sergey_prokofiev
                                  05.09.2017 08:56
                                  #10398582
                                  -1

                                  Если есть — тогда почему ни A380 ни 787 не полетели в заранее запланированные сроки и их разработка не уложилась в бюджет?

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


                              1. andreylartsev
                                05.09.2017 11:38
                                #10398916

                                Ммм, вы меня не поняли Сергей, 20 лет назад комерческие продукты поставлялись на CD, или даже на магнитных дискетах. И цикл разработки нового релиза длительностью 5 лет был нормой.
                                В современном мире обновления модных клауд сервисов и/или популярных Web сайтов поставляются на ежедневной основе.
                                И технологии и процессы разработки эволюционировали черезвычано сильно, но что осталось неизменным — это человеческая природа.
                                И конфликт внутри команды по прежнему может повлиять на сроки и бюджет сильнее чем любые технические риски.


                                1. sergey_prokofiev
                                  05.09.2017 12:34
                                  #10399056
                                  -3

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


                                  1. khim
                                    05.09.2017 13:58
                                    #10399288
                                    +3

                                    Кстате базовые инструменты митигирования этих рисков как то
                                    — унификация всего чтоможно унифицировать
                                    — максимально возможная независимость от «незаменимых» сотрудников
                                    — разумное документирование
                                    — ротация людей между командами
                                    Приводят к тому, что Westinghouse и Areva так и не построили в XXI веке ни одного реактора, а Росатом — строит их «на потоке». Потому что Кириенко (да-да, «тот самый» Кириенко) в ответ на вопрос в чём причина успехов отвечает не задумавшись отвечает: "«Нам удалось сделать ГЛАВНОЕ: сохранить наших людей, наших Специалистов с большой буквы, преданных делу всей душой. Все остальное на фоне этого – вторично"

                                    Дело в том что митигируя «human factor» риски вы не получаете «высокую кухню». Если всё сделано правильно — вы получает «McDonalds» — конвеерное производство, порождающее много одинаково посредственного продукта.

                                    А IT устроено так, что тиражировать даже самую дорогую вещь, в происзводство которой вложены миллиарды — можно почти бесплатно, потому потребность в Макдональдсах резко снижена.


                                    1. sergey_prokofiev
                                      05.09.2017 15:06
                                      #10399492
                                      -3

                                      А IT устроено так, что тиражировать даже самую дорогую вещь, в происзводство которой вложены миллиарды — можно почти бесплатно, потому потребность в Макдональдсах резко снижена.

                                      Вы это Tata Consulting расскажите. Предварительно поинтересовавшись их операционными показателями.
                                      А всякие гуглы с фейсбуками умудряются комбинировать «высокую кухню» со следованием корпоративным стандартам и буквально диктовке инженерам не только как им код писать, какому релиз циклу следовать, но и тому как им(например) публично высказывать свое отношение к гомосексуалистам. Смешные правда, не то что гордые фриланцыры?


                                      1. khim
                                        05.09.2017 18:41
                                        #10400120
                                        +1

                                        Вы это Tata Consulting расскажите. Предварительно поинтересовавшись их операционными показателями.
                                        Поинтересовался. 385 тысяч сотрудников, 17.5 миллиардов выручки, меньше $50'000 в год на человека. Притом, что в McDonalds — 375 тысяч сотрудников, 24.6 миллиардов выручки.

                                        То есть ваша Tata Counsulting — это, в буквальном смысле McDondalds — по всем показателям.

                                        При этом тот же упомянутый вами Google — это 60'000 сотрудников, 90 миллиардов выручки, $1'500'00 на человека. Разницу ощущаете?

                                        А всякие гуглы с фейсбуками умудряются комбинировать «высокую кухню» со следованием корпоративным стандартам и буквально диктовке инженерам не только как им код писать,
                                        Не путайте осознанное решение следовать принятым стандартам с их выработкой. Вот это вот — ну никак непохоже на «интеграционные решения обязаны и должны спускаться сверху», согласитесь? В конце-концов где, как вы думаете, описанная мною история произошла?

                                        Как раз Facebook и Google — прекрасные примеры того, о чём говорится в статье: минимум решений принимается наверху, почти все предложения приходят «снизу». Но да, после того, как их обсудили и зафиксировали — они обязательны к исполнению.

                                        но и тому как им(например) публично высказывать свое отношение к гомосексуалистам.
                                        Вы это всерьёз? Нет, правда? Это обычная американская зацикленность на политкорректности. К разработке отношения не имеет.


                                        1. sergey_prokofiev
                                          05.09.2017 19:00
                                          #10400160
                                          -2

                                          То есть ваша Tata Counsulting — это, в буквальном смысле McDondalds — по всем показателям.

                                          Достаточно много аналогий прослеживается, особенно если в структуру доходов и расходов не вникать. Но делать из каких то поверхностных аналогий выводы, что Tata «хуже макдональдса» — это какой то треш. Прибыльность фирмы сравнима с прибыльностью IBM и Oracle.
                                          Это тоже лузеры и неудачники, которые должны завидовать макдональдсу?
                                          Вот это вот — ну никак непохоже на «интеграционные решения обязаны и должны спускаться сверху», согласитесь?

                                          Где вы там интеграционные решения увидели?
                                          А вот код конвенции таки спускаются сверху, не так ли?
                                          Как раз Facebook и Google — прекрасные примеры того, о чём говорится в статье: минимум решений принимается наверху, почти все предложения приходят «снизу».

                                          В статье говорится что наверху вообще не надо принимать решений:
                                          Если вы решаете за сотрудников как им работать — вы не команда. Вы спускаете сверху git flow, список статусов задач, рабочие часы с 9:00 до 18:00? Похоже, вы упрощаете себе жизнь за счет того, что не пытаетесь найти правильное решение в конкретной ситуации? А может быть, чтобы отчитаться перед руководством о переходе на git flow? Оооо… да вы формалист. Только сама команда знает в каких условиях она может работать эффективно и только сама команда знает какие инструменты им нужны для работы. Если вы навязываете ваши правила против воли команды — вы не руководитель.

                                          так что давайте не будем передергивать.


                                          1. khim
                                            05.09.2017 21:48
                                            #10400420
                                            +1

                                            Где вы там интеграционные решения увидели?
                                            Конкретно там — их нету, это правда. Но вроде как в соотвествии со всеми «практиками» подобные вещи должны тоже «спускаться сверху», разве нет?
                                            А вот код конвенции таки спускаются сверху, не так ли?
                                            По моим ссылкам как раз и были приведены обсуждения этого документа (вернее его соседа). Код конвенции утверждается «наверху» (хотя, на самом деле, нет — этим занимается не начальство, а эксперты по Java/C++/etc), но предожения принимаются от совершенно рядовых членов команды — и если они звучат разумно, то воплощаются в жизнь независимо от того, кто их высказал.

                                            Ровно как в статье, которую мы обсуждаем, рекомендуют.

                                            В статье говорится что наверху вообще не надо принимать решений:
                                            Серьёзно? Где?

                                            Вы же сами привели цитату:
                                            Если вы навязываете ваши правила против воли команды — вы не руководитель.
                                            А теперь фигнёй страдаете:
                                            так что давайте не будем передергивать.
                                            Передёргиваете тут, в основном, вы. Стремясь утвердить в головах ложную дихотомию: либо руководитель «ломает всех об колено», либо он «вообще не принимает решений».

                                            Хороший же рукодитель выступает, скорее, в качестве арбитра в спорных случаях. Если же наблюдается, более-менее, консенсус, то худшее, что может сделать руководитель — идти против всей команды. Я сам лично присутствовал пару раз на совещаниях где все присутствующие, кроме руководителя подразделения, были за одно решение, а он — за другое… разумеется был выбран вариант, который хотела команда. Если же мнения разделяются 50/50 — то тут нужно сначала попытаться одну из сторон сменить своё мнение, либо, на крайний случай, выбрать одно из решений и да, таки утвердить его.

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


                                            1. sergey_prokofiev
                                              06.09.2017 10:46
                                              #10401398
                                              -3

                                              Конкретно там — их нету, это правда.

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

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

                                              Вот просто интересно. Сколько у вас лет работы на посте менеджера, сколько проектов вы сделали и каким кол-вом людей вы руководили?
                                              Я ставлю на то, что ваш опыт даже меньше предполагаемого опыта автора статься(полгода-год из 12 лет фриланса, на прямой вопрос он не ответил).


                                              1. khim
                                                06.09.2017 17:17
                                                #10402554
                                                +1

                                                Сколько у вас лет работы на посте менеджера
                                                Нуль.
                                                сколько проектов вы сделали
                                                Точно не скажу, но в зависимости от того как считать (только крупные или все, только те, в которых я был техлидом или те, где техлидом был кто-то другой) — от трёх до пары десятков.
                                                и каким кол-вом людей вы руководили?
                                                Максимум в моей команде было человек пять, ну так никто и не говорит, что в команде их должна быть тысяча. Любая команда, в которой более десятка человек — обычно разделяется на более мелкие компоненты (не обязательно жёстко, сейчас у нас в команде 6 человек, так что делить нечего, но на предыдущем месте их было где-то 20-25 и было, соответственно, 6 полунезависимых команд — но при этом некоторые люди входили сразу в несколько).

                                                При этом под моим непосредственным менеджером до недавнего времени было 67 непосредственных «report»ов, так что у него просто физически не было времени на то, чтобы принимать технические решения — для этого техлиды есть.

                                                Так что не нужно думать, что я тут описываю что-то, о чём я только в книжках читал, Ok?


                                                1. sergey_prokofiev
                                                  06.09.2017 18:54
                                                  #10402928
                                                  -1

                                                  Нуль.

                                                  Пожалуй с этого вопроса надо было начинать. Ну да ладно, лучше позже чем никогда.
                                                  Так что не нужно думать, что я тут описываю что-то, о чём я только в книжках читал, Ok?

                                                  Отчего же — вы вполне себе неплохо описываете типичные фантазии технаря про «этих мудаков менеджеров».
                                                  Но вам не хватает опыта с другой стороны баррикад. Наберетесь — перечитайте тред, уверен что найдете его забавным и может быть даже поучительным.
                                                  Засим откланиваюсь.


                                                  1. khim
                                                    06.09.2017 21:20
                                                    #10403274
                                                    +1

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

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

                                                    Менеджер выполняет роль смазки в двигателе. Но небольшой и хорошо организованный коллектив в ней не нуждается — как не нуждается в ней точно рассчитанный и качественно изготовленный керамический двигатель.

                                                    Конечно сделать двигатель на 10 мегаватт, работающий без смазки, не получится — и, начиная с какого-то масштаба, без менеджеров не обойтись.

                                                    Но так же, как и с двигателем — чем лучше у тебя «подогнаны детали», тем меньше требуется смазки и тем выше КПД.

                                                    Вот и всё.


                                          1. khim
                                            06.09.2017 01:29
                                            #10400848
                                            +2

                                            То есть ваша Tata Counsulting — это, в буквальном смысле McDondalds — по всем показателям.
                                            Достаточно много аналогий прослеживается, особенно если в структуру доходов и расходов не вникать. Но делать из каких то поверхностных аналогий выводы, что Tata «хуже макдональдса» — это какой то треш. Прибыльность фирмы сравнима с прибыльностью IBM и Oracle.
                                            IBM — это такой странный симбиоз. 90% компании — это такой же McDondalds, как и Tata, но есть ещё и IBM Research, который кардинально отличается от остальной части компании и ближе, скорее, к «гуглам с фейсбуками».

                                            Не знаю точно про Oracle, но подозреваю, что там — та же история.

                                            Да и кто вам сказал, что я ненавижу McDondalds? Это — вполне успешное заведение. И людей, которые там проработали полгода-год и не «удавились на галстуке» я тоже уважаю. Но их подход — это не то, как нужно разрабатывать уникальный софт, вот и всё.

                                            Это тоже лузеры и неудачники, которые должны завидовать макдональдсу?
                                            Нет, лузеры и неудачники — это люди, которые там работают десятилетиями. Пойти туда и отработать 3-5-7 лет, чтобы получить хоть какой-нибудь опыт? Нормально. Оставаться там работать на всю жизнь? Ну это как проработать 50 лет в McDondalds'е!


                                            1. sergey_prokofiev
                                              06.09.2017 10:52
                                              #10401416

                                              Но их подход — это не то, как нужно разрабатывать уникальный софт, вот и всё.

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


                                              1. khim
                                                06.09.2017 17:20
                                                #10402566
                                                +2

                                                Почему то каждый пионер уверен что он разрабатывает «уникальный софт»(тм), в команде «лучших профессионалов», а все остальные просто фигней страдают.
                                                Даже работая в McDonalds'е стоит думать о том, как, всё-таки, делается нормальная еда. Если вы, конечно, хотите быть поваром, а не просто пришли в McDonalds за подработкой.

                                                Потоковую потогонную систему, когда делается чёрт знает что чёрт знает зачем (потому что заказчик захотел) я тут не рассматриваю потому что за всё время работы я сталкивался с ней на протяжении, возможно, нескольких месяцев — и желания общаться с ней дальше у меня нет ровным счётом никакого. Как и у автора статьи.


                          1. sshikov
                            04.09.2017 21:43
                            #10398190
                            +1

                            Хм. Вы никогда не видели бизнес, который не умеет ставить задачи четко и однозначно? Вы никогда не видели исследовательских проектов? Серьезно?


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


                            1. sergey_prokofiev
                              04.09.2017 21:55
                              #10398204
                              -1

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

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


                              1. khim
                                04.09.2017 23:36
                                #10398308
                                +2

                                Безусловно, разные проекты требуют разных процессов, но при росте масштабов проектов и требованиях к повторяемости результата
                                Более нелепого утверждения я в жизни не видел. При росте мастабов проекта «требования к повторяемости» никак не могут расти. Просто потому, что это невозможно. Вы можете выйти на уровень, где вы можете успешно и в оговоренные сроки сделать что-нибудь в среднеразмерном проекте (ну, например, автоматизировать управление производством в цеху в 100-200 человек), если же вы делаете что-то реально крупное — то у вас неизбежно будут накладки и проблемы, которые все «150 лет практик» не разрешат и вам придётся полагаться на команды, подобные описанным в статье.

                                И неважно — разрабатываете вы самолёт или строите плотину, пишите операционку или движок для какой-либо игры. Если вы делаете что-то уникальное не очень похожее на аналоги (или если этих аналогов просто нет), то вам нужна команда, если вы что-то разрабатываете в 100500й раз, то достаточно «наработанных практик».

                                От масштаба зависит не так много, важна повторяемость процесса. И здесь программирование резко отличается от многих других дисциплин, так как во многие случаях то, что в других случаях потребует переделки и адаптации проекта (что, как раз, можно сделать используя «наработанные за 150 лет практики») в случае с софтом просто не нужно. Вы не будете возить почту из одной деревни с населенем в 100 человек в другую подобную же тем самым A380 — не окупится. Но можете взять движок, рассчитанный на миллионы посетитей — и ничего в нём не меняя разместить на нём бложик с посещением 100 человек в год.


                                1. sergey_prokofiev
                                  05.09.2017 09:11
                                  #10398604
                                  -3

                                  Если вы делаете что-то уникальное не очень похожее на аналоги (или если этих аналогов просто нет), то вам нужна команда

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


                                  1. khim
                                    05.09.2017 14:03
                                    #10399306

                                    А что ещё вы можете делать в IT? Клепать копии того, что кто-то однажды уже сделал?

                                    Ну так производитель оригинала снизит цену — и вы останетесь «на бобах». Себестоимость-то копии нулевая — сколько бы ни стоил оригинал!


                                    1. sergey_prokofiev
                                      05.09.2017 15:12
                                      #10399534
                                      -3

                                      Детский сад, право.
                                      99.99% всего промышленного девелопмента — это интеграция уже готовых кусков кода в нужной последовательности.


                                      1. khim
                                        05.09.2017 19:32
                                        #10400208
                                        +1

                                        Вы ещё скажите, что весь девелопмент — это расположение нуликов и единичек на флешке так, чтобы получился нужный результат.

                                        Бессмысленное обобщение никому ни о чём не говорящее.


          1. franzose
            05.09.2017 03:48
            #10398410
            +1

            Думаю, тут очень кстати будет фраза из одного замечательного фильма: «Я хотя бы попробовал!». Человек высказал, в общем-то, дельные мысли, дискуссия таки завязалась :)


      1. akjoler
        04.09.2017 11:16
        #10397082

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


        1. vryashentsev Автор
          04.09.2017 11:18
          #10397088
          -1

          Новую команду набирать не обязательно. Вполне можно изменить старую. Был свидетелем. Но состав немного изменился.


          1. akjoler
            04.09.2017 11:29
            #10397114
            -2

            А я у вас спрашивал — что обязательно, а что не обязательно? Что за менторство? Попробуйте уважать собеседника. Вы меня убедили: общаться с вами не комфортно и скушно.


            1. vryashentsev Автор
              04.09.2017 11:38
              #10397138

              Логика — наш главный ментор!
              Я был свидетелем преобразования пропащей команды в хорошую -> набирать новую команду не обязательно.


              1. TimTowdy
                04.09.2017 21:37
                #10398180
                +1

                Может об этом и напишете статью? Что привело к деградации команды, как на это решили повлиять, какие получились результаты. Живой опыт всегда интересен.


                1. vryashentsev Автор
                  04.09.2017 21:40
                  #10398184
                  +1

                  Почему бы и нет. Запишу эту тему в копилку тем, на которые хочу написать статью.


  1. Nickola75
    04.09.2017 11:01
    #10397060
    +3

    В общем, поделюсь ситуацией, которая, откровенно говоря, патовая. Партнеры уходят, конкуренты обходят, а начальства ничего не может с этим поделать. И пойдем прям по пунктам.
    1. Все дружно молчат. Что начальство, что остальные сотрудники. Когда я поднимаю тему составления плана выхода из сложившейся стагнации, никто должным образом не реагирует. Хотя уже бонусы не платят пол года и перспектив выхода никаких.
    2. Работаем, как и положено, с 9 до 18, но при этом задач с гулькин нос. В основном, мелкая текучка. А там, кто чем занимается: народ смотрит фильмы, рисует, читает. Начальству вообще до лампочки.
    3. Руководители появляются и уходят, как призраки. Ничего толкового не сообщают ни то, что отделу разработки, но и менеджерам.
    4. Целеустремленность работников близка к 0. Стагнация уже больше года, и все становится только хуже. Народ думает, как свалить, но, естественно, все молчат.
    5. Есть одно большое обещание от руководства, что скоро будет большой проект. И все будет хорошо. По этому проекту действительно ведутся переговоры. Но уже как пол года ни к чему не приводят.
    Вот, что значит «эффективная команда».


    1. vryashentsev Автор
      04.09.2017 11:04
      #10397066
      +1

      Мне это напоминает поведение новичков в покере — сделали ставку и продолжают повышать, не желая терять первоначальную ставку и надеясь на то, что карта придёт. В итоге проигрывают много больше, чем могли себе позволить.


      1. zharikovpro
        04.09.2017 11:25
        #10397102
        +4

        Это общечеловеческое.

        Каждый год профессор Макс Базерман продает студентам MBA из Harvard Business School двадцатидолларовую купюру намного выше номинала. Его рекорд – продажа $20 за $204. А делает он это следующим образом.


  1. iit
    04.09.2017 11:26
    #10397108
    +10

    Здравствуй автор, я тот чувак, который как раз и читает новелки на работе.
    Ну для начала у нас на проекте действительно есть старая но сплоченная команда которая работает в месте 5 лет.


    Да есть проблемы — вся команда бывает страдает фигней, при этом половина команды еще и жутко былокодит и велосипедит, даже я обычно пишу классный модуль kiss, SOLID, DDD по всем канонам с фабриками и DI но и этот код обрастает костылями из за которых мы получаем иногда очень веселые глюки. В этом хаосе я вижу множество причин.


    1. Бизнесу пофиг на технический долг, даже когда он ему прямо угрожает. Каждый лепит костыли на велосипедах и подпирает их костылями — я даже нарисовал костыльного монстра который должен придти и сожрать всех. Задачи на рефакторинг — в свободное время. Первое время я ими занимался час после работы, потом дома до полуночи и в итоге бывший студен стал женатым серьезным человеком и уже нет времени копаться в легаси дома в свободное время и без оплаты.
    2. Бизнес не знает чего хочет, на каждую задачу идет как минимум 10 итераций правок, с 10-50 правками на каждую итерацию. Самый сок — когда менеджеры с дизайнерами устраивают войну правок — мы запасаемся попкорном.
    3. Бизнес может заключить договор с парнерами, мусолить 2 месяца этот проект между собой, дать задачу сделать дизайн (не веб и не адаптивный) которую дизайнеры еще 2 недели делают и придти к нам в пн — мол в пятницу все должно быть готово. Естественно срок срывается и мы косячники а партнеры в ярости. Итог — дизайнеров мы притянули в наш отдел чтобы когда у них возникала новая задача мы уже начинали делать фронт и бэк по ней чтобы хоть как-то успевать.
    4. Если честно мотивировать нас сложно и нам самим сложно внедрять инновации. У меня ушло пол года чтобы заставить каждого из коллег поставить php-storm/idea ubuntu, локально развернуть nginx и 3 наиболее часто используемые на проектах версии php (5.4, 5.6, 7.1) и развернуть проекты локально с наиболее близкой к серверам конфигурациями, и заставить юзать git. Были еще предложения вроде визуализации, zabbix, закупки новых серверов, покупки bitbucket и jira. Но бизнес был глух — только когда наняли "крутого тимлида" со стороны он смог протолкнуть все это.

    При этом команда все еще умудряется не развалиться. Несмотря на такой "хороший" менеджер, не ушла к конкурентам (причем были и те кто хотел взять сразу всю команду с +150% к окладу каждому а мне так вообще x3) находит способы раскидывать проекты сами и более менее дружна даже не смотря на то что мы перетираем коммиты друг друга. Сейчас все налаживается но все еще далеко от идеала. Но веры менеджерам нет — это раз, и напрягаться никто выше того за что нам платят не собирается так как менеджмент этого не видит.


    1. vryashentsev Автор
      04.09.2017 11:32
      #10397126
      +7

      Спасибо за историю. А почему всё таки команда не перешла целиком на столь выгодных, в материальном плане, условиях?


      1. sergeyns
        04.09.2017 14:53
        #10397562
        +3

        Слишком разленились


        1. iit
          05.09.2017 06:42
          #10398470

          Ну во первых было ломы это верно, во вторых та компания которая собиралась нас нанимать — разделила бы команду по разным отделам, и в третьих поковыряв знакомых мы нашли чувака из их конторы — у них такие же проблемы как у нас и при этом они уже наняли и распустили 2 команды до нас. Смысла идти в компанию которая путь и платит больше но уже разогнала 2 команды до нас — мы как-то не видели.


          1. vryashentsev Автор
            05.09.2017 06:48
            #10398474

            К сожалению, я не понял вашей позиции в итоге. Можете пояснить?


            1. iit
              05.09.2017 10:53
              #10398738

              Есть контора А где мы там


              • легаси, костыли и велосипеды
              • проблемы с менеджерами
              • нормальная оплата
              • спокойная работа
              • есть хорошая команда из 6 человек где я — middle php back, еще два middle frontend (jquery+nodejs+backbone) один php back+teamlead и еще два хороших таких fullstack студента которые с нами уже 3 года.

              Есть контора Б которая предлагает работу и у них


              • ушли 2-е команды разрабов (полностью весь штат)
              • легаси, костыли и велосипеды
              • 5 проектов по 1-2 человека на проект (нашу команду бы разделили на 5 команд)
              • проблемы с менеджером
              • высокий оклад и возможность получить акции компании

              В итоге есть контора которая предлагает нам двойной и тройной оклад но работы у них больше и из за проблем с управлением проектами от них ушли две команды — знакомый из последней рассказал что там все плохо и есть проблемы с проектами и управлением. Плюс большая часть стэка куплена у москвичей и с ней есть проблемы. В итоге мы решили остаться при своихзнакомых костылях и велосипедах, плюс в текущей конторе hr поднял ставку в 1.5 раза. Решили остаться.


      1. Danik-ik
        05.09.2017 08:03
        #10398528
        +2

        Мой дядя любит рассказывать байку про друга, "дважды еврея советского союза" (в смысле, уехал, а потом вернулся). Почему вернулся? Да там кругом одни евреи! Там, чтобы выжить, работать надо!


        Я на таком упадническом настроении когда-то вообще ушёл из разработчиков. Это был интересный опыт. С трудом вернулся через восемь лет.


    1. franzose
      06.09.2017 02:48
      #10400930

      Бизнесу пофиг на технический долг, даже когда он ему прямо угрожает. Каждый лепит костыли на велосипедах и подпирает их костылями — я даже нарисовал костыльного монстра который должен придти и сожрать всех. Задачи на рефакторинг — в свободное время.

      Мне всегда было странно, почему бизнес этого не понимает. Даже поговорка есть: поспешишь — людей насмешишь. То есть не всегда срабатывает быстрый говнокодинг для занятия какой-то ниши, так как потом так или иначе приходит пора допиливания и поддержки. А проект уже, оказывается, превратился в один большой big ball of mud и настолько запутан, что выпуск новых фич занимает всё больше и больше времени.


      1. khim
        06.09.2017 03:29
        #10400948
        +2

        Мне всегда было странно, почему бизнес этого не понимает.
        Классический эффект айсберга. Вот это вот:
        Бизнес может заключить договор с парнерами, мусолить 2 месяца этот проект между собой, дать задачу сделать дизайн (не веб и не адаптивный) которую дизайнеры еще 2 недели делают и придти к нам в пн — мол в пятницу все должно быть готово.
        Проистекает из того, что они искренне считают, что раз дизайн в Photoshop нарисован — значит 90% дела сделано. Помните:
        Люди, которые не являются программистами, смотрят на экран и видят какие-то пиксели. И если кажется, что эти пиксели могут собраться в программу, которая что-то делает, они думают «да ну, сколько там ещё осталось, чтобы она просто начала действительно работать?»
        Удивительным образом люди, способные это понять — не всегда бывшие программисты (хотя это помогает) и не всегда бывшие программисты способны это понять (вот это меня удивляет всегда больше всего).


      1. sergey_prokofiev
        06.09.2017 11:00
        #10401432

        А вот правильно, с цифрами, обьяснить бизнесу, почему им необходим тот или иной рефакторинг, вписать его в бизнес план, скоммуницировать с командой, что «мы все обязательно исправим, но поэтапно, первый шаг через 3 месяца, вот таска в жире» — это одна из задач менеджера. Хорошего менеджера :)


        1. khim
          06.09.2017 17:31
          #10402626

          Это правда, конечно, но есть странный парадокс: чем более вменяем у вас «бизнес» и чем больше о его нуждах знает команда (и, наоборот, чем больше знает о нуждах команды бизнес), тем меньше потребность в менеджерах. В предельных случаях (когда бизнес не очень большой — скажем до 50-100 человек) можно обойтись и без него вообще.


          1. sergey_prokofiev
            06.09.2017 19:44
            #10403052
            -1

            В предельных случаях (когда бизнес не очень большой — скажем до 50-100 человек) можно обойтись и без него вообще.

            А платить то кто будет? Это шедевр, распечатаю и повешу на стену. Сори, не удержался :)


            1. khim
              06.09.2017 20:10
              #10403106

              В предельных случаях (когда бизнес не очень большой — скажем до 50-100 человек) можно обойтись и без него вообще.
              А платить то кто будет?
              Бухгалтерия, однако. Скорее всего — даже не входящая в штат компании.

              Это шедевр, распечатаю и повешу на стену. Сори, не удержался :)
              Пожалуйста, мне не жалко.


              1. sergey_prokofiev
                06.09.2017 20:12
                #10403112

                Бухгалтерия, однако

                Это еще один шедевр, очень кратко и однозначно идентифицирующий ваше понимание бизнеса.
                В небольшом бизнесе на 50-100 человек внезапно появляется какая то отдельная от бизнеса бухгалтерия, готовая платить «за все» — это прекрасно, продолжайте в том же стиле :)


                1. khim
                  06.09.2017 21:26
                  #10403300
                  +1

                  В небольшом бизнесе на 50-100 человек внезапно появляется какая то отдельная от бизнеса бухгалтерия, готовая платить «за все» — это прекрасно, продолжайте в том же стиле :)
                  Знаете вас вопрос и мой ответ — это классическое: «а откуда деньги» — «из тумбочки».

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

                  Зачем тут ещё какой-то менеджер и в чём будут состоять его обязанности — мне решительно непонятно.

                  И да — это не теоретические изыски, это то, как были устроены большинство компаний в которых я работал (да-да их была не одна и не две).


  1. Eldhenn
    04.09.2017 11:29
    #10397116
    +4

    Забавный текст. В части «как не» — описана конкретика, примеры фейлов, которые можно примерить на себя, можно обобщить.
    В части «brave new world» — лозунги («Наши действия подчинены общей цели» и т.п.)
    Ощущение, что мне в очередной раз пытаются что-то продать.


  1. marshinov
    04.09.2017 11:29
    #10397118
    +1

    Impact mapping. Gojko Adzic (не представляю как по-русски написать
    Гойко Аджич он:)


  1. sergey_prokofiev
    04.09.2017 11:39
    #10397142
    -2

    Инфантилизм 80лвл. Некоторые из тезисов важны, некоторые — нет, сама подборка — детский сад.
    Сходите в Tata Consulting и расскажите им что не надо решать за сотрудников как им работать, поинтересовавшись предварительно ее макропоказателями.


  1. LbISS
    04.09.2017 11:40
    #10397146

    Мне кажется выводы в статье как-то с потолка. "Идеал — вот так, плохо — вот так". Что с этим делать и какие могли быть причины? Почему это — хорошо, а вот это плохо?
    Команда — это динамическое образование. У неё есть стадии развития, зависимость от корпоративной культуры, от цели. Для каждой корпоративной культуры и стадии развития понятие "идеальной" команды — разное. Описание идеала в статье прекрасно может подходит для "бирюзовых" компаний в которых большая часть сотрудников уже давно работает, но для какой-нибудь жесткой конкуретной компании "up or out" с хорошей текучкой это неприменимо вообще и с таким "идеалом" задачи IT подразделение выполнять не сможет.
    В целом это всё хорошо расписано в книгах по регулярному менеджменту и командообразованию, а в статье зафиксирована только односторонняя позиция которая подается как общий идеал. Стоит добавить всё-таки в каких компаниях вы работали и в каких условиях для команды можно ориентироваться на эти положения.


  1. fedor7
    04.09.2017 12:02
    #10397200
    +2

    Класс! Статья, как ориентир, как описание (недостижимого?) идеала, к которому нужно стремиться. Хотя бы не забывать смотреть в эту сторону. И пусть идеализм.


  1. terrier
    04.09.2017 12:18
    #10397220
    -2

    Так, сударь, похвастайтесь предметно. Расскажите о той идеальной команде, в которой вы работали и, что более интересно, расскажите о той почти идеальной команде, которую вы создали, назовите названия компаний.
    Неловко будет, если выяснится, что все, что вы накропали — это фантазии на опыте мелкого аутсорсера из Томска, правда?


    1. vryashentsev Автор
      04.09.2017 12:31
      #10397248

      «Накропал» в личку.
      Я не стесняюсь показывать своё лицо, рассказывая свои мысли. А вы?


      1. terrier
        04.09.2017 12:52
        #10397288

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


        1. vryashentsev Автор
          04.09.2017 13:01
          #10397322

          Давайте я попробую прояснить свою позицию.

          если бы вы назвали козлом

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

          Вам кажется, что git flow спускают для того, чтобы отчитаться

          Нет, мне так не кажется. Я уже ответил на подобный комментарий habrahabr.ru/post/337048/#comment_10396832

          У меня складывается ощущение, что вы придираетесь к примерам, на которых я объяснял свою позицию, а не к самой позиции. Зачем? Примеры это просто красочные вымышленные ситуации.

          «правила разработки» — это заговор злых корпоративных зомби

          И опять мне так не кажется. А кажется мне, что команда сама сформирует правила работы и будет их яростно отстаивать.


          1. terrier
            04.09.2017 14:03
            #10397478
            -1

            сказать о проблеме, которая тебя беспокоит.

            Тут ничего выдумывать не надо, надо следовать установленному процессу. Если у тебя кондиционер барахлит — звони по телефону 007 в хозслужбу. Если с жирой неполадки — пиши админам. Если есть что сказать по процессу разработки — назначай встречу со своим линейным менеджером. А вот директора козлом называть — неразумно и проблему не решает. Кстати, как вы думаете, откуда эти хорошие процессы берутся? Может быть их команда выдумывает?

            Нет, мне так не кажется. Я уже ответил на подобный комментарий

            Из-за вашей специфики у вас какой-то странный страх перед неким «насильственным внедрением». На самом деле внедрить процессы никого не насилуя — задача типичная для менеджера и хорошо описанная (хотя может быть в реальной жизни и не тривиальная).


            1. vryashentsev Автор
              04.09.2017 14:09
              #10397490

              откуда эти хорошие процессы берутся?

              Да, полагаю, именно команда. Но вы отделяете команду от менеджера, а я — нет.


        1. vryashentsev Автор
          04.09.2017 18:11
          #10397900
          +2

          Подумав еще…
          Да, мой опыт действительно специфичен. В дальнейшем постараюсь обращать больше внимания описанию контекста.


    1. bopoh13
      04.09.2017 12:44
      #10397274
      +1

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


      1. terrier
        04.09.2017 12:54
        #10397300

        В данном случае — это оффтоп, но в реальном мире у разработки в Томске, Саратове, Киеве, Москве или Сан-Франциско есть серьезные особенности и игнорировать их нельзя.


  1. transGLUKator
    04.09.2017 12:34
    #10397256
    +2

    Кому интересна техника Impact Mapping могу порекоммендовать онлайн инструмент для построения IM, который позволяет создавать, шарить и экспортировать карты в pdf и png. uxpressia.com/impact-map-online-tool


  1. Xandrmoro
    04.09.2017 12:58
    #10397314
    +1

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


  1. Amomum
    04.09.2017 13:06
    #10397352
    +2

    Если вы решаете за сотрудников как им работать — вы не команда. Вы спускаете сверху git flow, список статусов задач, рабочие часы с 9:00 до 18:00?

    Мой небольшой опыт показывает, что если кто-нибудь (необязательно РМ или начальство, просто кто-то, кому не все равно) не придумает, как организовывать работу (банально, конвенции по именованию файлов/директорий, конвенции по кодированию, rebase или merge и т.д.), то все будут делать это как попало. Если всех не приучить юзать git, то у кого-то вообще никакого версирования не будет, кто-то будет архивчики руками делать ежедневно, кто-то svn себе поставит. И код будет расползаться просто файлами по скайпу.

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


    1. vryashentsev Автор
      04.09.2017 13:11
      #10397380

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


    1. vryashentsev Автор
      04.09.2017 13:14
      #10397390

      Но педалировать надо не git, часы работы и конвенции, а правила командной работы. Иначе погрязнете в микроменеджменте.


      1. vlad_54
        04.09.2017 14:23
        #10397510
        +1

        Как правильно заметил коллега с «небольшим» опытом, пока вы не определите основные правила, конвенции, workflow… вы не получите общего движения всей команды в одном направлении. Если у вас будет 3,5,7 команд работающих в одном проекте ваша теория приведет к появлению «лебедь, рак и щуки», и вам придется навязать каждой конкретной команде правила, которые возможно одобрит не каждая команда. Это придется сделать, и как не странно именно для того что бы предоставить больше свободы в действиях, при чем в рамках существующих ограничений. Ведь «основная задача руководителя — создавать условия труда, а не раздавать команды.»


        1. vryashentsev Автор
          04.09.2017 14:24
          #10397516
          -2

          3, 5, 7 команд работающих в одном проекте — да, возможно, в этом случае не сработает. Но вы ведь не пробовали, верно? Справедливости ради скажу, что я тоже не пробовал в таких условиях.


        1. Amomum
          04.09.2017 15:06
          #10397592
          +3

          Я не руководитель, опыт у меня и правда небольшой (да еще в одной компании), я просто вижу проблемы вокруг себя. У нас даже просто сидящие в разных концах комнаты люди умудрялись развивать маленькие фабрики велосипедов, несовместимые друг с другом. Просто потому, что они не общались. Каждый сидит в своем углу и делает свое маленькое дело. Что происходит, когда люди сидят в разных комнатах — я вообще молчу.

          Отмечу, что у нас своя специфика, очень много небольших проектов, поэтому разработчикам существенно проще не контактировать друг с другом. Но тем не менее.


          1. franzose
            05.09.2017 00:52
            #10398342

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

            Ну да. Отсутствие или неполнота коммуникации и общепринятых стандартов в команде — рассадник решений «на коленке», причём повторенных у разных людей по-разному, грубо говоря, об одном и том же. Вы как-то с этим боретесь? Или это уже устоявшаяся практика?


            1. Amomum
              05.09.2017 12:30
              #10399040
              +2

              Пытаемся. Наиболее инициативные товарищи образовали т.н. «Совет Эльфов», который принимал все судьбоносные решения подобного рода. Но всегда есть несколько человек, с которыми ничего не поделать. Или встают в позу, или отмахиваются, или просто не видят проблемы. Вот тут бы, на мой взгляд, как раз и стоило бы слегка надавить «административным ресурсом», которым совет не обладает :)


  1. franzose
    04.09.2017 14:30
    #10397530
    +6

    Статья добротная. Но вот еще бы понять, как бороться с синдромом Not Invented Here и с тем, что «нам некогда заниматься изучением чего-то там, нам надо писать код», сиюминутным исполнением задач без вдумчивого анализа и хватанием за голову впоследствии...


    1. vryashentsev Автор
      05.09.2017 06:59
      #10398482
      -1

      Ох, всё так индивидуально. Лидер должен взять выработку пути на себя.


  1. lpwaterhouse
    04.09.2017 15:21
    #10397616
    -2

    Если вы не знаете целей и интересов ваших сотрудников — вы не команда

    От работодателя требуется лишь исправно платить зарплату. Еще не хватало, чтобы он в личную жизнь лез.


    1. vryashentsev Автор
      04.09.2017 19:00
      #10397980
      +1

      Вы высказали ваши интересы, которые важно знать и принимать во внимание, чтобы ужиться с вами. А план профессионального роста хотите составить с руководителем? Скажем научитесь делать то и то, пройдёте курсы, сделаете еще один проект и получите такую-то зарплату? Это тоже можно назвать целью.


  1. TatyanaUpgrade
    04.09.2017 21:50
    #10398200
    +2

    Это прекрасно, когда у тебя в багаже есть опыт работы в здоровых системных компаниях. И особенно помнятся, конечно, их колелктивы! Мнение автора имеет место быть.


  1. le1ic
    04.09.2017 22:44
    #10398254

    Согласен с 3- 5 пунктами. п.1 это просто эпатаж, у автора его много.

    с п.2 не согласен, ситуации бывают разные, и не все проекты длятся несколько месяцев, бывают проекты на много лет, приход-уход людей неизбежен, у бизнеса (или у владельцев бизнеса) есть долгосрочные цели кроме проекта, такие как business continuity, compliance итд. Поэтому когда сверху спускают git (или даже cvs) и рабочий день с 9 до 18, у этого могут быть свои основания.


    1. vryashentsev Автор
      05.09.2017 07:04
      #10398484
      -2

      1-ый пункт между прочим самый важный. Таки почитайте.

      По второму пункту еще раз напишу, что нет противоречия между «выгодно для бизнеса» и «команда решает как работать». Точнее конфликт может быть, но лидеру нужно его разрешить. Иначе Команды не получится.


  1. Captain
    05.09.2017 13:13
    #10399168

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


    1. vryashentsev Автор
      05.09.2017 13:57
      #10399280

      И опять повторю — нет противоречия между выгодой бизнеса и командностью.

      интересы команды говорят — надо перейти на другой фреймворк

      Это предположение.
      Я вот другого мнения — все мы сидим на игле общественного одобрения. Все хотят быть полезными. Поэтому разработчик хочет сделать так чтобы бизнес им был доволен.


    1. khim
      05.09.2017 14:16
      #10399340

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

      А интересы команды говорят — надо перейти на другой фреймворк, все отрефакторить, все обвешать тестами и т.п.
      Это те же самые интересы безнеса — только в будущем.

      И угадайте кто чьими интересами должен проникнуться.
      А не нужно ничем «проникаться», нужно посчитать. Слева — сколько займёт внедрение нового фреймворка, справа — ожидаемый выигрыш. Не можете такого написать? Даже прикидок нет? А тогда с чего вы решили, что переход на новый фреймворк вообще имеет смысл?


      1. Captain
        05.09.2017 14:44
        #10399428

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


  1. AlexPee
    05.09.2017 13:58
    #10399284

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

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


    1. shurutov
      05.09.2017 16:52
      #10399852

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

      Не надо так делать. Ничего хорошего в таких совещаниях нет и неизвестно. За всю свою жизнь ни разу не встречал коллективов, где бы подобные совещания чему-то способствовали. Либо таковые встречи заканчивались плачевно для коллектива/проекта/компании, либо прекращали быть (тоже плачевно для коллектива, потому что приводили к смене руководителя, а новый руководитель — он и есть новый руководитель).


      1. vryashentsev Автор
        05.09.2017 16:58
        #10399878

        Планы отдела огласить и обсудить полезно. Ретроспективу провести тоже полезно. Но, пожалуй, рассказывать о планах и задачах каждого — громоздковато будет.


        1. shurutov
          05.09.2017 17:10
          #10399926

          План+ретроспектива — соглашусь;
          обсудить — только при необходимости, каковая имеет место быть далеко не всегда.
          А вот обсуждение планов и задач каждого — оно не только громоздко, оно нередко выливается в какое-нибудь громогласное непотребство, которое приходится пресекать руководителю.
          Соответственно, такой сбор — оно уже совсем не совещание, а какая-нибудь планёрка минут на 5-15.


          1. AlexPee
            06.09.2017 09:23
            #10401236

            Разбираться с «непотребством», как вы высказались, и есть одна из задач руководителя, надо понимать почему оно возникает, если у человека есть боль и он ей делится, то ее надо решить, скорее всего это не только у него наболело. А если человек себя намеренно так ведет, то наверное ему не место в коллективе. Это как раз позволяет прокачивать коммуникационные и прочие навыки, поэтому вижу в этом скорее плюс, чем минус.


            1. shurutov
              06.09.2017 12:34
              #10401678

              Разбираться с «непотребством», как вы высказались, и есть одна из задач руководителя

              Спасибо за понимание. А то тут много чего понаписали про то, что руководитель не нужен. Либо о том, что команда вполне себе может решать задачи, которые обязан решать руководитель.
              Про боль. По личному моему опыту начинать решение проблем всё-таки предпочтительнее с приватной беседы. Боль — она вполне себе может быть обусловлена личными причинами, озвучивать которые публично вполне себе может быть не совсем приемлемо.
              И самое главное — когда появляется боль, требующая внимания руководителя, эту боль надо решать немедленно, а не на плановом совещании.
              И второе. Я как-то вот так предпочитаю направлять свои усилия, чтобы исключить вероятность нештатных ситуаций, а не решать проблемы. Соответственно, комфортно себя чувствую только там, где руководители понимают, что предотвратить проблему существенно дешевле, нежели постоянно решать возникающие проблемы.


      1. franzose
        06.09.2017 02:41
        #10400926

        У нас в коллективе ежедневные планёрки — и ничего страшного. Как по мне, это наоборот помогает, когда проговариваешь, что делал вчера, что собираешься делать сегодня. Даже если планы в итоге нарушаются. По крайней мере, все более менее в курсе, что происходит с проектами.


        1. vryashentsev Автор
          06.09.2017 03:35
          #10400952

          За день не накопится очень много задач и планов. Ежедневные планерки полезны в таком формате.


      1. AlexPee
        06.09.2017 09:19
        #10401226

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


        1. shurutov
          06.09.2017 12:22
          #10401656

          в свободной манере и коллегам, это нравиться

          Процитированное — это ключевые словосочетания.
          Обобщая свой опыт, не зная вот вот этих ключевых слов, сделал безапелляционное заявление, был неправ, прошу прощения.
          Но час на обсуждение. Регулярно. По некоторым причинам мне от этого грустно. :(


  1. mik
    06.09.2017 00:44
    #10400806

    Текст — клише с позитивной коннотацией.


  1. AstRonin
    07.09.2017 10:03
    #10403986

    А я вот чего не пойму, тут есть пункт:

    Общая цель формулируется так, что учитывает цели каждого. Более или менее. Если есть человек, цель которого мешает достижению общей цели — он покидает команду.

    т.е., если не получилось (не хватило опыта/знаний) завлечь человека своей целью, то он просто выкидывается. И до каких пор так? Пока не находится человек достаточно лояльный/«пластилиновый»/неуверенный или признаётся, что ты не руководитель и надо уходить самому?
    Ведь очень удобный пункт, так можно увольнять всех подряд, не замечая, что проблема в руководителе…


    1. vryashentsev Автор
      07.09.2017 10:30
      #10404060

      Руководитель один из тех людей, который становится вредным если его цель не совпадает с целью компании/проекта. И его обязательно надо гнать, если так случилось. Если руководитель не смог завлечь общей целью, то либо проблема в цели, либо надо менять руководителя.


      1. sergey_prokofiev
        07.09.2017 13:00
        #10404518
        -1

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

        Тоесть если руководитель успешно завлек 50 человек и с 51м не получилось — то он плохой руководитель, его надо менять. Это прекрасно :)


        1. vryashentsev Автор
          07.09.2017 14:49
          #10404788
          +1

          Данное утверждение останется на вашей совести )