Сударь, ваша команда — не команда

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

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

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


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

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


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

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

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


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

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

    Выводы


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

    Спустите пар


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

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

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

    На почитать


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

    Comments 254

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

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

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

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

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

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

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

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

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

                        0
                        Не знаю, большинство проектов, что я видел, длятся годами. Типа какого-нибудь дропбокса, который сделали, и дальше только допиливают… Новые задачи разве что в стиле «переписать этот модуль» да «заменить тот». Плюс есть в команде люди с правом вето, у которых «Ну этой технологии всего 2 года, хз что из этого выйдет, не будем копаться в непроверенной хипстерской хрени» © почти цитата.
                    +2
                    С git flow всё в порядке, а вот насильное внедрение чего бы то ни было — не порядок.

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


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

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

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

                      [/sarcasm off]
                        0

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

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

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

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

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

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

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

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

                                И тоже самое будет на общем собрании при наличии некоторой критической массы увлеченного народа.
                                Несомненно. Но если они неготовы работать в компании, которая приняла решение, идущее «вразрез» с их желаниями — значит они недостаточно увлечены (или, что то же самое, чрезмерно увлечены мелочами, которые, по большому счёту, не так важны — что то же самое: если вы готовы из-за спора «табы vs пробелы» сорвать релиз… то ясно же, ради чего вы работаете — разве нет?).
                                  –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х чисел. Числа получают в каком то контексте и с какими то исходными данными и предположениями. И дальше можно до бесконечности жонглировать как исходными данными, так и результатами, что мы и наблюдаем на очень многих технических форумах.
                                  Но если они неготовы работать в компании, которая приняла решение, идущее «вразрез» с их желаниями

                                  … то, если верить автору статьи, команда с такими вот разработчиками, сама должна бесконечно долго решать использовать пробелы или табы, а начальство никоим образом не должно команду прессовать.
                                    +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
                                    Там обсуждается интересный феномен: разработчики, испольщующие Табы в среднем получают меньше денег. Понять — экономи при это деньги бизнес или теряет из ваших «посиделок на кухне» невозможно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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


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

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


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

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

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

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

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

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

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

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

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

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

                                        Как вы сами сказали, в игру будет вступать авторитет отдельных членов команды. Это будет происходить всегда, и в этом случае польза от цифр сильно падает, т.к. свою основную роль (объективность) они уже не выполняют. Максимум что они вам дают — возможность предостеречься от глупых ошибок, например писать на Brainfuck, потому что «авторитет» так захотел.
                                  +2
                                  А теперь у вас продукт пишется четырьмя отделами/командами. Одна юзает git flow, другая просто git, третья mercurial, четвётрая svn. Потому что они лучше знают, что им удобнее.
                                  Интересно, что вы почти точно описали что у нас происходило лет так примерно 5 назад. Правда gitflow у нас не было, но svn и mercurial — были. И людям, которые предлагали это всё заменить на git пришлось долгое время поддерживать альтернативных клиентов и обьяснять все преимущества git'а в мире, где центральные сервера используют mercurial и SVN.

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

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

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

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

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

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

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

                                            –5
                                            Еще как поставишь и KPI есть во всех крупных компаниях. Как только количество инженеров в проекте начинает измеряться десятками — моментально появляется статистика и соотвественно инструменты для измерения производительности каждого программиста.
                                              +4
                                              Там и появляется «китайский» и «индусский» код. Я вас уверяю — фирмы, пишущие в 10'000 строк то, что можно написать в 100 не получают более дешёвого и качественного продукта — это иллюзия.
                                                –3
                                                А причем тут «дешевый и качественный код», я про него где нить упоминал? Я говорил исключительно про повторяемость и гарантированность результата, что зачастую для бизнеса в сотни раз важнее чем дешевизна и качество.
                                                  +1

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


                                                  Я переведу на понятный: наш заказчик заплатил за неспешное образование и душевные переживания нашей команды.
                                                    –3
                                                    Вы так ничего и не поняли. Заказчик платит за гарантию результата в сроки, что достигается отлаженным процессом с одной стороны, оплатой грамотного менеджмента — с другой.
                                                      +4

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

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

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

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

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


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


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

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

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

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

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

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

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


                                                                    Норм диалог.

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

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


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

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


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

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


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

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


                                                                  «360 degree review»

                                                                  См. п. 1.

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

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

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

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

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

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

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

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

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

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

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

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

                                                  Просто небольшая заметка: пример Сингапура в этом плане довольно интересен.
                                                    0
                                                    Угу, а второй пример — Южная Корея. Но на этом всё, потому что подавляющее большинство остальных диктаторов до добра страну не доводили.
                                                      +1
                                                      Но «идеальные» диктаторы таки бывают и они далеко не редкость. Но у всех одна проблема — преемники и тут диктатура дает сбой в 9 случаях из 10(Октавиана Августа выносим за скобки — это было мегакруто :) )
                                                  0

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

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

                                                      Я тоже видел. Только к большому сожалению, такая система не стабильна. И непонятно, как ее такую построить.

                                                        0
                                                        Мне понятно как построить такую стабильную систему. Могу помочь — обращайтесь.
                                                0
                                                По моему истина где-то посередине. Приведу простой пример. Я работаю в конторе, где для работы над продуктом мы вынуждены были портировать код под нормальные архитектуры от wintel «команды». Эти лохи используют древнючие компиляторы из-за которых куча ненужных костылей в коде, и даже ими толком не умеют пользоваться, не используют систему контроля версий (точнее у них начальник использует VSS просто тупо складывая туда надерганные файлы от других разработчиков) в результате невозможно даже движение наших патчей критинизма назад и каждый новый релиз кода этих орлов это серьезная головная боль для всей цепочки. Это явная ситуация, где необходим принудительный перевод на git flow начала цепочки, принудительное соблюдение стандартов, стиля кодирования, изменение архитектуры, подхода к тестированию, релиз планов…
                                                  0

                                                  Так если вводить git flow принудительно — то в итоге их начальник будет складывать в git flow файлы, надерганные от других разработчиков. Думаете, будет лучше? :-)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                                          Вот это качество у 80% программистов идет из коробки. «Я программист, мое дело код писать, а дальше трава не расти. Закоммитил, работа выполнена...»
                                                            +3
                                                            Прикол в том, что когда даже не совсем подходящие кадры приходят в слаженную команду — они принимают правила игры и вливаются.
                                                              +2

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

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

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

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

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

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

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


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

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

                                                                            Плоблема в том, что Элопа, фактически, наняли для того, чтобы он аккуратно изменил стиль разработки и урезал бюрократию — как это сделал Луи. А он, вместо этого, решил всё «до основания разрушить» и… остаться у разбитого корыта. Для этого много ума не нужно, знаете ли.
                                                                          +1
                                                                          Согласен. Каждый должен заниматься своим делом. Управление проектами — это специальность, которой 5 лет учат в вузе(в пост советских — плохо учат), а не тягание квадратиков в жире, как многие думают и как зачастую это бывает в реальной жизне, увы.
                                                                          Специфика безусловно влияет(причем обратно пропорционально масштабу проекта), но не более чем понимание предметной области программистом: хорошо бы если бы отельер с 20 годами опыта переквалифицировался и напедалил booking.com, он то ситуацию изнутри знает. Но в реальности оно бывает немного не так :)
                                                                        +2
                                                                        Не обязательно программистом. Может быть аналитиком или тестеровщиком. Вариантов масса.
                                                                          0

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

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

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

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

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

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


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

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

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


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

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

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

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

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

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

                                                                                            В идеальном мире возможно.
                                                                                          0
                                                                                          Практика показывает, что в больших командах, особенно с большой wintel частью не выберут и не быстро и git тут лишь верхушка айсберга. Единственное, что остается делать профессионалам так это медленно и планомерно создать невыносимые условия для неэффективных подходов и простые и легкие для эффективных.
                                                                                            +1
                                                                                            Единственное, что остается делать профессионалам

                                                                                            Из вашего поста сквозит несколько откровенно нелепых утверждений, например «кто использует гит — тот профессионал», «кто не использует гит — тот не профессионал», «wintel — это плохо».
                                                                                            Вас кто-то обидел на работе, что ли? Кто вас укусил, разработчик Delphi, сидящий под SVN, или разработчик C++, сидящий под VSS?
                                                                      0
                                                                      Команда кристаллизуется вокруг решения общей проблемы и с учётом человеческих взаимоотношений. А не специальным образом соответствующими кадрами.
                                                                      Как уже замечено, новые люди либо принимают правила и становятся частью, либо отторгаются.
                                                                        0

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

                                                                          0
                                                                          Вот это качество у 80% программистов идет из коробки. «Я программист, мое дело код писать, а дальше трава не расти. Закоммитил, работа выполнена...»
                                                                          Такое очень зависит от начальства, работая в предыдущей фирме, где контролировали каждую минуту времени и навязывали технологии, я так себя и вел)
                                                                          Сейчас же мне больше повезло с начальством и даже без задач знаю чем себя занять и как улучшить проект
                                                                          +8
                                                                          Какая-то безапелляционная и снисходительная манера подачи… Сколько людей, столько и команд — идеала нет, от слова совсем (советы, типа: «радуйтесь», бесят). В каждой системе есть полезные концепции, есть не очень, есть смешные. Считаете что вам повезло: бывает… хотя, может вам просто хотелось саморекламы?
                                                                            +6
                                                                            Рад, что я вас задел. Это была одна из целей. Но давайте по существу.
                                                                              +5
                                                                              imho, основные тезисы статьи:
                                                                              • Я работал в команде, а вы нет
                                                                              • Ваша команда — не команда
                                                                              • Вы находитесь на этапе провала
                                                                              • Вам никогда не жить в прекрасном мире
                                                                              • Я молодец ибо работал в команде и построил команду
                                                                              • Вот вам пара банальных книг


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

                                                                                Тезисы примерно верны, но один вы упустили:
                                                                                • Вот вам правила, взяв которые за основу, вы можете построить Команду.
                                                                                  +5
                                                                                  Самое забавное то, что судя по введению, аффтар и в командах толком не работал, и с проектами средней продолжительности не сталкивался, не говоря уже о саппорте: за 12 лет опыта аж 2 раза работал в команде и сменил «около 10» мест работы — смена места работы — раз в год.
                                                                                  Но считает свое мнение достаточно важным и авторитетным для того, чтобы постить стать на хабре.
                                                                                    +1
                                                                                    Среднее значение не всегда отражает реальную картину. Может быть два раза по пять лет и восемь раз по три месяца.
                                                                                      0
                                                                                      Это возможно. Могу разве что попросить топикстартера дать больше инфы о своем опыте: продолжительность проектов, размеры команд, количество команд работающих над одним солюшнем…
                                                                                        –2
                                                                                        Да, скорее всего, сделаю это позже. Пока еще не пришло время.
                                                                                          0
                                                                                          Опять какой то детский сад и тайны мадридского двора.
                                                                                            0
                                                                                            Перечитал ваши комментарии и обнаружил, что не было ни одного по существу. Все обо мне. Приглашаю вас почитать мои будущие статьи — возможно, я заинтересую вас еще больше.
                                                                                              +5
                                                                                              Плохо читаете. Ну да ладно, напишу прямым текстом, мне не жалко.
                                                                                              Тезис 1. Программирование есть инженерия.
                                                                                              Тезис 2. За крайние 150 лет были наработаны вполне определенные практики управления большими коллективами инженеров, во многом идущие в разрез с опубликованными «рекомендациями».
                                                                                              Тезис 3. Все велосипедостроение процессов разработки характеризует состояние менеджмента во многих IT проектах. Впрочем в крупных проектах менеджеры вынуждены ставить нормальные процессы, и у меня складывается отчетливое впечатление, что ваши «рекомендации» идут исключительно от полного непонимания как организовывать работу средней команды в ~50 инженеров(приблизительно половина — девелоперы) на в проекте продолжительностью в пару лет.
                                                                                                +1
                                                                                                Перечитал комментарии еще раз. Действительно один комментарий по делу:
                                                                                                Сходите в Tata Consulting и расскажите им что не надо решать за сотрудников как им работать

                                                                                                Ок, зачту.

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

                                                                                                Гениально!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                                                                                          Вот как раз такие интеграционные решения обязаны и должны спускаться сверху и жестко контролироваться.
                                                                                                          И, опуская дальнейшие цитаты, отмечу в очередной раз, вы мне приписываете какие то идеи из своей головы. Я нигде не писал что начальство обязано спускать и контролировать абсолютно все. Хороший менеджмент — это всегда баланс между крайностями, понимание того что можно отдать на откуп команде, а что «спустить сверху».
                                                                                                  +3
                                                                                                  Интересно что термин «нормальные процессы», я впервые услышал чуть больше 20 лет назад и с тех пор слышал великое разнообразие определений от различных инженеров как именно они должны выглядеть. За 20 лет они довольно сильно эволюционировали и крайне трудно между ними выбрать что-то общее, разве только то, что нельзя инженеру мешать творить то что он хочет, и как он хочет, даже если его понимание того что должно быть сделано отличается от того что нужно для бизнеса.
                                                                                                    +1
                                                                                                    Нормальный процесс — это SDLC процесс позволяющий выдавать предсказуемый результат в оговоренный срок с заранее запланированным уровнем качества, с учетом рисков.
                                                                                                    А вот
                                                                                                    нельзя инженеру мешать творить то что он хочет, и как он хочет, даже если его понимание того что должно быть сделано отличается от того что нужно для бизнеса.

                                                                                                    явный признак полного бедлама в процессе:
                                                                                                    — инженер должен не «творить» а проектировать
                                                                                                    — у «инженера», его коллег, менеджмента должно быть четкое и общее понимание целей и путей их достижение
                                                                                                    — задачи должны быть поставлены и донесены четко и однозначно
                                                                                                    — бизнес должен ставить задачи и принимать результат, отнюдь не диктовать имплементацию.
                                                                                                      +7
                                                                                                      Сергей, нет никакого SDLC который позволяет выдавать предсказуемый результат в оговоренные сроки с заранее запланированным качеством, бюджетом и с учетом рисков.
                                                                                                      Это Миф. А программирование, точнее разработка ПО, уж извините, далеко не только инженерия.
                                                                                                        –5
                                                                                                        Сергей, нет никакого SDLC который позволяет выдавать предсказуемый результат в оговоренные сроки с заранее запланированным качеством, бюджетом и с учетом рисков.

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

                                                                                                        Не сомневаюсь, что у некоторых это «искусство», «творение» и так далее по шаблону своих братьев по духу, недоучек-гуманитариев. У них, кстате, постоянные проблемы со сроками, догадываешься почему?
                                                                                                          +1
                                                                                                          Истина где-то посередине. Действительно есть ряд проектов где можно выдать предсказуемый результат и сроки, и в них «творцы» очень часто наносят ущерб. С другой стороны есть немало проектов, где в основе лежит только идея, а требования могут меняться чуть ли не каждый день. И тут, несмотря на то, что это остается инженерией, очень сложно предоставить большую предсказуемость. Собственно на этой основе и появилась потребность в гибких методология.
                                                                                                            –1
                                                                                                            Дык вся неопределенность выносится на уровень менеджмента. Программист все так же рутинно открывает ишью трекер, читает стори, эстимирует, педалит, перевешивает сторю на тестировщиков. А менеджмент беклога, который становится коротким и непредсказуемым — это уже к лидам и менеджерам, инженерии тут(почти) нет, равно как от инженера не требуется ничего кроме инженерии(возможно — лучшая квалификация чтобы поддерживать codebase во вменяемом состоянии при бардаке с требованиями).
                                                                                                            +1
                                                                                                            Сергей, нет никакого SDLC который позволяет выдавать предсказуемый результат в оговоренные сроки с заранее запланированным качеством, бюджетом и с учетом рисков.
                                                                                                            Есть.
                                                                                                            Если есть — тогда почему ни A380 ни 787 не полетели в заранее запланированные сроки и их разработка не уложилась в бюджет?

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

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

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

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

                                                                                                                    Вы это Tata Consulting расскажите. Предварительно поинтересовавшись их операционными показателями.
                                                                                                                    А всякие гуглы с фейсбуками умудряются комбинировать «высокую кухню» со следованием корпоративным стандартам и буквально диктовке инженерам не только как им код писать, какому релиз циклу следовать, но и тому как им(например) публично высказывать свое отношение к гомосексуалистам. Смешные правда, не то что гордые фриланцыры?
                                                                                                                      +1
                                                                                                                      Вы это Tata Consulting расскажите. Предварительно поинтересовавшись их операционными показателями.
                                                                                                                      Поинтересовался. 385 тысяч сотрудников, 17.5 миллиардов выручки, меньше $50'000 в год на человека. Притом, что в McDonalds — 375 тысяч сотрудников, 24.6 миллиардов выручки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

                                                                                                                      Ну так производитель оригинала снизит цену — и вы останетесь «на бобах». Себестоимость-то копии нулевая — сколько бы ни стоил оригинал!
                                                                                                                        –3
                                                                                                                        Детский сад, право.
                                                                                                                        99.99% всего промышленного девелопмента — это интеграция уже готовых кусков кода в нужной последовательности.
                                                                                                                          +1
                                                                                                                          Вы ещё скажите, что весь девелопмент — это расположение нуликов и единичек на флешке так, чтобы получился нужный результат.

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

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

                                                                                              0
                                                                                              По моему мнению, любая существующая команда уже представляет некую ценность (патологии бывают, но не часто и определяются на старте). Правильно сориентировать каждого игрока, суметь нейтрализовать/погасить трения и научиться выигрывать этим составом — вот что работает, по моему опыту. И по факту это гораздо быстрее, чем «набрать новую команду» и эффективнее. Хотя эта работа не так наглядна, без особого драматизма и эффектных штук.
                                                                                                –1
                                                                                                Новую команду набирать не обязательно. Вполне можно изменить старую. Был свидетелем. Но состав немного изменился.
                                                                                                  –2
                                                                                                  А я у вас спрашивал — что обязательно, а что не обязательно? Что за менторство? Попробуйте уважать собеседника. Вы меня убедили: общаться с вами не комфортно и скушно.
                                                                                                    0
                                                                                                    Логика — наш главный ментор!
                                                                                                    Я был свидетелем преобразования пропащей команды в хорошую -> набирать новую команду не обязательно.
                                                                                                      +1
                                                                                                      Может об этом и напишете статью? Что привело к деградации команды, как на это решили повлиять, какие получились результаты. Живой опыт всегда интересен.
                                                                                                        +1
                                                                                                        Почему бы и нет. Запишу эту тему в копилку тем, на которые хочу написать статью.
                                                                                            +3
                                                                                            В общем, поделюсь ситуацией, которая, откровенно говоря, патовая. Партнеры уходят, конкуренты обходят, а начальства ничего не может с этим поделать. И пойдем прям по пунктам.
                                                                                            1. Все дружно молчат. Что начальство, что остальные сотрудники. Когда я поднимаю тему составления плана выхода из сложившейся стагнации, никто должным образом не реагирует. Хотя уже бонусы не платят пол года и перспектив выхода никаких.
                                                                                            2. Работаем, как и положено, с 9 до 18, но при этом задач с гулькин нос. В основном, мелкая текучка. А там, кто чем занимается: народ смотрит фильмы, рисует, читает. Начальству вообще до лампочки.
                                                                                            3. Руководители появляются и уходят, как призраки. Ничего толкового не сообщают ни то, что отделу разработки, но и менеджерам.
                                                                                            4. Целеустремленность работников близка к 0. Стагнация уже больше года, и все становится только хуже. Народ думает, как свалить, но, естественно, все молчат.
                                                                                            5. Есть одно большое обещание от руководства, что скоро будет большой проект. И все будет хорошо. По этому проекту действительно ведутся переговоры. Но уже как пол года ни к чему не приводят.
                                                                                            Вот, что значит «эффективная команда».
                                                                                              +1
                                                                                              Мне это напоминает поведение новичков в покере — сделали ставку и продолжают повышать, не желая терять первоначальную ставку и надеясь на то, что карта придёт. В итоге проигрывают много больше, чем могли себе позволить.
                                                                                                +4
                                                                                                Это общечеловеческое.

                                                                                                Каждый год профессор Макс Базерман продает студентам MBA из Harvard Business School двадцатидолларовую купюру намного выше номинала. Его рекорд – продажа $20 за $204. А делает он это следующим образом.
                                                                                              +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) находит способы раскидывать проекты сами и более менее дружна даже не смотря на то что мы перетираем коммиты друг друга. Сейчас все налаживается но все еще далеко от идеала. Но веры менеджерам нет — это раз, и напрягаться никто выше того за что нам платят не собирается так как менеджмент этого не видит.

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

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

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

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


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

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


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

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

                                                                                                    +2

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


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

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

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

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

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

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

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

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

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

                                                                                                                  И да — это не теоретические изыски, это то, как были устроены большинство компаний в которых я работал (да-да их была не одна и не две).
                                                                                                      +4
                                                                                                      Забавный текст. В части «как не» — описана конкретика, примеры фейлов, которые можно примерить на себя, можно обобщить.
                                                                                                      В части «brave new world» — лозунги («Наши действия подчинены общей цели» и т.п.)
                                                                                                      Ощущение, что мне в очередной раз пытаются что-то продать.
                                                                                                        +1
                                                                                                        Impact mapping. Gojko Adzic (не представляю как по-русски написать
                                                                                                        Гойко Аджич он:)
                                                                                                          –2
                                                                                                          Инфантилизм 80лвл. Некоторые из тезисов важны, некоторые — нет, сама подборка — детский сад.
                                                                                                          Сходите в Tata Consulting и расскажите им что не надо решать за сотрудников как им работать, поинтересовавшись предварительно ее макропоказателями.
                                                                                                            0

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