Комментарии 254
Понятно, что творческий коллектив — это несколько иное (наверное), но это означает, что команда у нас есть :). Мы все приходим к 8-30 (начинаем работать в 9), уходим в 18-30 и позднее (офф — 18), видимо осознавая ценность дисциплины. И работа в выходные — не палочная, а по велению души.
Спасибо, что еще раз подтвердил, что у нас все относительно благополучно.
осознавая
Вот! Это главное слово для строительства любой рабочей системы.
Хобби-проекты — да, причем пилим с коллегами. И были случаи, когда такой х-п (точнее полученные на нем навыки) дал возможность выиграть тендер.
Видел интересную мысль на хабре по этому поводу. Своими словами могу сформулировать так: Правило одного нового. Команда делает или новый проект на известном стеке технологий, или команда делает типовой проект на новом стеке технологий.
Команда делает или новый проект на известном стеке технологий, или команда делает типовой проект на новом стеке технологий.Это не всегда удаётся. Но даже в этом случае полезно разделить команду на две — одна будет пилить новые технологии (если старые по каким-то причинам не подходят), другая — новый проект на старых (но консультируясь иногда с первой командой, чтобы в момент, когда новые технологии будут готовы не пришлось всё выкинуть к чертям собачьим).
Зависит от людей. Некоторых и пинать не надо, а другие только по указивке сверху шевельнутся освоить что-то новое, соответственно, если указивок нет, то и развития нет.
С git flow всё в порядке, а вот насильное внедрение чего бы то ни было — не порядок.
Взгляните со стороны менеджмента. Унификация процессов внутри компании это очень важно: можно легко перекинуть человека с одного проекта на другой и он в разумные сроки начнет давать результат. Во-вторых, упрощается администрирование: появляются шаблоны проектов, системные администраторы и dev ops начинают раворачитьвать рабочее окружение за часы, а не недели.
Это все чертовски важно. Ваш же подход программистко центричен, если так можно выразиться, а в компании обычно работают не только программисты, но и devops, тестировщики, внедренцы и т.д.
Или нет, давайте пусть весь проект будет в одной системе, пусть вся команда решит. Соберём все четыре отдела (40 человек) в большом митинг-руме и пусть выбирают что им удобнее. Заказчик пусть подождёт окончания холиворов. Руководитель… а что руководитель, это не его дело выбирать в чём команде работать!
[/sarcasm off]
В большинстве случаев он все равно не выберет...
А потом дадим слова тестировщикам — им тоже есть что обсудить и из чего выбрать.
Затем предлагаю устроить митинги по выбору языка программирования, среды разработки, ишью трекера, системы документации, код конвенций, используемых библиотек-фреймворков, баз данных, архитектуры в конце концов…Очень хорошее предложение. Без сарказма.
А потом дадим слова тестировщикам — им тоже есть что обсудить и из чего выбрать.
Есть одно но: слова «а мне нравится» может произносить только и исключительно руководитель (ведь зачем-то он таки нужен?) — а все остальные могут высказывать любые предложения по какому угодно поводу… но с цифрами в руках.
Вы не поверите насколько такое правило снижает накал дискуссий: все эти бесконечные споры, которые занимают годы обычно ведутся путём переливания «из пустого в порожнее» просто потому что обсуждаются какие-то абстрактные вещи, которые ни измерить, ни оценить невозможно.
Если подобные споры запретить — то окажется, что и у тестировщиков умные мысли встречаются. И гораздо чаще, чем вам кажется.
И тоже самое будет на общем собрании при наличии некоторой критической массы увлеченного народа.
Народ десятилетиями аргументировано и с цифрами обсуждают проблемы табы&пробелы, виндовс&линукс, .NET&Java&C++&..., микросервисы&монолиты и так далее по спискуНе приведёте ссылочек, если народ «аргументировано и с цифрами» что-то там обсуждает?
любая популярная проблема, не имеющая однозначного ответа просто обречена на бесконечный холивар.В том-то и дело, то тема может быть холиварной только в том случае если чисел нет.
Если числа есть — то выбирается более выгодный вариант и всё.
P.S. Под числами я понимаю что-то, что как-то связано с деньгами, которая получит фирма. Так-то в любом споре про табы и пробелы буду два числа: 9 и 32. Но если у вас нет на фирме модулей для которых это важно, то только от того, что 9 < 32 немного, а если есть — то тема перестаёт быть холиварной и становится вполне технической, с единственным ответом.
И тоже самое будет на общем собрании при наличии некоторой критической массы увлеченного народа.Несомненно. Но если они неготовы работать в компании, которая приняла решение, идущее «вразрез» с их желаниями — значит они недостаточно увлечены (или, что то же самое, чрезмерно увлечены мелочами, которые, по большому счёту, не так важны — что то же самое: если вы готовы из-за спора «табы vs пробелы» сорвать релиз… то ясно же, ради чего вы работаете — разве нет?).
Не приведёте ссылочек, если народ «аргументировано и с цифрами» что-то там обсуждает?
У вас забанили и гугл и яндекс? Ок, один раз приведу
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х чисел. Числа получают в каком то контексте и с какими то исходными данными и предположениями. И дальше можно до бесконечности жонглировать как исходными данными, так и результатами, что мы и наблюдаем на очень многих технических форумах.
Но если они неготовы работать в компании, которая приняла решение, идущее «вразрез» с их желаниями
… то, если верить автору статьи, команда с такими вот разработчиками, сама должна бесконечно долго решать использовать пробелы или табы, а начальство никоим образом не должно команду прессовать.
У вас забанили и гугл и яндекс? Ок, один раз приведуТам обсуждается интересный феномен: разработчики, испольщующие Табы в среднем получают меньше денег. Понять — экономи при это деньги бизнес или теряет из ваших «посиделок на кухне» невозможно.
stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs
evelinag.com/blog/2017/06-20-stackoverflow-tabs-spaces-and-salary/#.Wa6Hoa2mNTY
И дальше можно до бесконечности жонглировать как исходными данными, так и результатами, что мы и наблюдаем на очень многих технических форумах.Тогда что это за числа, если из них нельзя сделать выводы? Так-то любой текст в компьютере это «числа». Речь же не об этом.
если верить автору статьи, команда с такими вот разработчиками, сама должна бесконечно долго решать использовать пробелы или табы, а начальство никоим образом не должно команду прессовать.Вы плохо прочитали статью, однако.
Прессовать — не нужно, но…
Общая цель формулируется так, что учитывает цели каждого. Более или менее. Если есть человек, цель которого мешает достижению общей цели — он покидает команду.Если у вас нет консенсуса на тему — использовать табы или пробелы, но есть больгинство, которое готово на какой-то один вариант — то либо меньшинство соглашается с мнением большинства, либо меньшинство просто уходит.
Если вас спросили о чём-то, то это означает, что хотят узнать ваше мнение по какому-то вопросу, но это не означает, что если ваше мнение не совпадает с мненим большинства, то вам позволят бесконечно долго транжирить время всех остальных участников команды.
Тогда что это за числа, если из них нельзя сделать выводы?
Базовые числа, от которых надо отталкиваться при принятии решений. Если, к примеру, выбирать между .NET и Java, то есть огромное количество всевозможных бенчмарков, обоснований, экспериментов и так далее в пользу каждого из решений. И иногда нужно волевое решение ответственного человека.
но есть больгинство, которое готово на какой-то один вариант — то либо меньшинство соглашается с мнением большинства, либо меньшинство просто уходит
А если (почти) поровну, как в случае в САПР на аэробусе? Как вы там описывали, саботаж неизбежен?
А если (почти) поровну, как в случае в САПР на аэробусе?Там не было «поровну». Там были «новаторы» французы и «консерваторы» немцы.
В такой ситуации — нужно было либо добиться консенсуса, либо сделать так, как было сделано, но чётко оговорить, что это сделано под ответственность немцев. А иначе — получаем то, что получаем.
Там не было «поровну». Там были «новаторы» французы и «консерваторы» немцы.
Ну вот если посчитать первых и других, по головам, то получится «поровну».
В такой ситуации — нужно было либо добиться консенсуса, либо сделать так, как было сделано, но чётко оговорить, что это сделано под ответственность немцев
Отличные варианты. Либо жевать сопли месяцами, либо сознательно пойти на факап, который таки случился «сам собой».
Идеи «поставить на рабочие компы одинаковый софт, организовав тренинги для обучения» канечна ни разу не рассматриваются.
Отличные варианты. Либо жевать сопли месяцами, либо сознательно пойти на факап, который таки случился «сам собой».Это были два единственных реалистичных варианта. Причём второй вариант — вовсе не гарантирует «факапа». Если вы проблему несовместимости двух версий софта не «заметаете под ковёр» и выясняете что кабеля не подходят к конструкции только уже при сборке самолёта, а проводите соответствующие эксперименты и оценки заранее — то вы такого факапа бы не получили.
Идеи «поставить на рабочие компы одинаковый софт, организовав тренинги для обучения» канечна ни разу не рассматриваются.Нет, потому что речь идёт о реальной компании с реальными людьми. И ставить «на уши» всю компанию (на самом деле даже несколько независимых компаний!) ради одного проекта без веских причин никто не будет.
Я надеюсь вы понимаете, что те же люди, которые разрабатывали A380 принимали участие также и в других проектах? Или вы думаете, что все десятки тысяч инженеров, которые этим занимались были подчинены только ему? Тогда бы там больше 6 миллиардов на одни зарплаты ушло!
Вы думаете что не всегда есть цифры, исходя из которых можно принять решение? Тогда вступает в игру авторитет отдельных членов команды.
Но это не стимулирует команду развиваться
Количество разработчиков не всегда является той цифрой, на основе которой принимается решение. Это был всего лишь пример для идеального описанного случае. Реальный случай естественно сложнее и учитывает больше факторов чем «я сказал, а вы сказали».
Ситуация не всегда идеальна. Иногда приходится использовать паршивые цифры полученные в результате голосования. Но я полагаю и в случае с написанием компилятора можно найти более полезные цифры.
Вы думаете что не всегда есть цифры, исходя из которых можно принять решение? Тогда вступает в игру авторитет отдельных членов команды.Цифры есть всегда, но обычно от них не так много толку. Цифры полезны тем, что они объективны, но они работают только когда вы сравниваете одинаковые вещи. Объективно сравнить 2 банана и 3 яблока вы не можете.
Допустим вы выбираете между Go, PHP и Python: PHP популярнее, но у вас в команде доминируют Go разработчики, и при этом большая часть софта уже написана на Python.
Как посчитать что даст большую прибыль компании, PHP, Go или Python? Кстати, на какую прибыль мы будем ориентироваться, долгосрочную или краткосрочную? (и это даже не выбор из двух вариантов, это непрерывная величина)
Как вы сами сказали, в игру будет вступать авторитет отдельных членов команды. Это будет происходить всегда, и в этом случае польза от цифр сильно падает, т.к. свою основную роль (объективность) они уже не выполняют. Максимум что они вам дают — возможность предостеречься от глупых ошибок, например писать на Brainfuck, потому что «авторитет» так захотел.
А теперь у вас продукт пишется четырьмя отделами/командами. Одна юзает git flow, другая просто git, третья mercurial, четвётрая svn. Потому что они лучше знают, что им удобнее.Интересно, что вы почти точно описали что у нас происходило лет так примерно 5 назад. Правда gitflow у нас не было, но svn и mercurial — были. И людям, которые предлагали это всё заменить на git пришлось долгое время поддерживать альтернативных клиентов и обьяснять все преимущества git'а в мире, где центральные сервера используют mercurial и SVN.
И они с этим справились! Хотя это и потребовало много времени, но зато все шероховатости были убраны до того, как все перешли на git — а если бы git-flow «внедрили указом», то все так бы и проклинали его годами вспомниная как клёво было когда их никто не заставлял «этим ужасом» пользоваться.
преимущества git'а в мире, где центральные сервера используют mercurial и SVN.
А в чём преимущество гита перед меркуриалом?
Я в своё время отказался от hg, т.к. тот не умел русские имена файлов под Windows. На заплатку FixUtf8 они забили… Похоже, воз и ныне там: WindowsUTF8Plan не обновлялся с середины 2014-го.
И они с этим справились! Хотя это и потребовало много времени, но зато все шероховатости были убраны
Я переведу на понятный: наш заказчик заплатил за неспешное образование и душевные переживания нашей команды.
Или так или платить за снижение мотивации работать. Программисту норму "15 гаек в час" не поставишь. Вроде работает, результат есть, а то, что его на 20% меньше, потому что его все бесит — не угадаешь
Вот тут вы говорили про цену кода:
Я переведу на понятный: наш заказчик заплатил за неспешное образование и душевные переживания нашей команды.
Это вы не поняли, что грамотный менеджмент следит за мотивацией сотрудников, а не за KPI.
И как же ее в таком случае измеряют? :-)
— кол-во эскалаций от сотрудников на менеджмент
— кол-во уволившихся-ротированных сотрудников
— рост зп(внезапно, если не сильно требуют, то низкий рост вместе с низкой ротацией — все довольны)
— удовлетворенность работой(опросники)
— «360 degree review»
Но это только вершина айсберга :)
Допустим, ваши KPI работают и выявляют что программисты халтурят. Каковы действия идеального менеджера?
После этих действий программисты все еще халтурят. Каковы действия идеального менеджера?
После этих действий программисты научились обходить KPI, показывая хорошую мотивацию в опросах. Но проект так и не ускорился. Каковы действия идеального менеджера?
После этих действий программисты научились обходить KPI, показывая хорошую мотивацию в опросах.
вы даже не понимаете, про какие KPI говориться в этом контексте.
Каковы действия идеального менеджера?
42
Именно такое у вас понимание предмета, извините дальше не вижу смысла в дискуссии.
А теперь 2 простых вопроса.
1. Является ли «моя мотивация» KPI сотрудника?
2. Является ли «мотивация подчиненных» KPI менеджера?
Потому что "команда решает, как ей работать" тождественно равно "бардак". Не всегда полный, но бардак гарантированный. Имею как жизненных (до ВУЗ-а), так и профессиональных примеров, когда команда "решала". Все (ВСЕ!) эти примерыр заканчивались плачевно, в лучшем случае — приглашением нового руководителя. Решатели плакали крокодильими слезами в таком случае. Есть примеров, когда команда дорешивалась до ликвидации компании, как самостоятельного лица (либо конкуренты покупали, либо банкротство, либо ещё что-нибудь такое "весёлое").
Решает ВСЕГДА руководитель. Он же и отвечает за принятые решения перед вышестоящим руководством и прочими инвесторами. И именно поэтому у руководителя з/п выше, чем у рядовых сотрудников. Члены же команды имеет право, а у хорошего руководителя, обязаны, сформулировать и предложить пожелания/требования к средствам и способам совместной работы. А руководитель, в свою очередь, обязан прислушаться к мнению своих подчинённых и выбрать наиболее соответствующие целям и задачам средства и способы.
А идеальным является руководитель, у которого в подчинении есть товарищи, у которых в договоре прописано разрешение публично объяснять руководителю глубину его некомпетентности не выбирая выражений. Я, правда, таких не встречал, к своему великому сожалению. :(
Потому что «команда решает, как ей работать» тождественно равно «бардак». Не всегда полный, но бардак гарантированныйАвторитарный руководитель точно также рано или поздно обеспечивает гарантированный бардак, посмотрите на опыт авторитарных правительств. Идеальная диктатура действительно гораздо эффективнее демократии, но беда в том, что идеальных диктаторов не бывает.
Есть примеров, когда команда дорешивалась до ликвидации компанииА примеров когда руководитель доводил до той же самой ликвидации вы не видели? Точно также есть примеры, когда компании с плоской структурой были вполне себе успешны.
Вы построили себе неопровержимую теорию — всегда должен быть авторитарный руководитель. Если это работает — теория хорошая. Если нет — все равно теория хорошая, просто руководитель был неправильный.
Не нужно бросаться в крайности. Бывают команды, где авторитарное правление дает положительные результаты, бывает наоборот.
Кто-то пострадал от «поэтов» в программировании, и пытается превратить его в армию, а кто-то наоборот, пострадал от диктаторов и пытается дать всем полную свободу. Советую обоим расширить свои взгляды. IT — это не армия, и не поэзия, оно где-то посередине.
беда в том, что идеальных диктаторов не бывает
Просто небольшая заметка: пример Сингапура в этом плане довольно интересен.
Если решает всё и всегда руководитель (интересно, а что, по-вашему, он решает?), есть риск того, что ответственность и качество работы в команде будет снижаться и снижаться. Т.к. всё, что останется делать разработчикам, — выполнять указания сверху.
Дело не в менеджерах. Программисты этим страдают не меньше. Особенно у них большая тяга переписать все на новый модный фреймворк. Это по всей видимости некая функция от природного любопытства и вера в магию.
Одно дело, когда врождённое любопытство и перфекционизм разработчика толкает на переписывание готового кода. Другое, когда сверху спускается необоснованное распоряжение из-за которого чуть ли не вся проделанная работа идёт псу под хвост.
Я все же думаю это одно и то же. Переписывание кода на новый фреймворк тоже пускает работу коту под хвост.
Зачастую действия менеджеров, а в частности приведённый выше пример направлен исключительно на ИБД для начальства. А для проекта это сродни саботажу.
Как правило, инициатива разработчика обоснована и направлена на реализацию конкретных целей, которые призваны улучшить продукт.
Это в идеальном мире. В нем же и манагеры хорошие вещи делают. Чаще всего на новый фреймворк переходя по принципу "все фигня, кроме пчел".
Я не против вашей идеи, но вы плохих менеджеров-карьеристов почему-то сравниваете с хорошими программистами. Естественно такое сравнение не в пользу менеджеров.
И еще интересное наблюдение. Комплекты в diablo 2. Надел одну вещь — просто вещь. Надел вторую — получил +20 к урону молнией и сопротивление от ядов. Качества каждого человека в команде это его личные качества + влияние команды.
Я стесняюсь спросить, а вы когда нанимаете кого-то на работу (допустим сантехник, электрик, доктор...) наверное тоже не против того, чтобы они попробовали что-то новое за ваш счёт?
Кстати, неверная аналогия у вас. Сантехнику за «что-то новое» платит компания, в которой он работает, а не конечный заказчик. Если сантехник работает сам на себя, то и платит за «что-то новое» он сам. Так же как и разработчики-фрилансеры.
Хоть сантехнику на зарплате, хоть фрилансеру
Только это происходит неявно — никому и в голову не придёт сказать клиенту «я тут решил поэкспериментировать за ваш счёт, гоните бабки» (если, конечно, это не учёные)
Просто расходы на развитие в виде обучения и экспериментов включены в счета за работу и раскиданы по всем клиентам
Если я кого-то нанимаю, то значит, качество и цена меня полностью устраивает. И я совершенно не буду возражать, если сантехник на эти деньги купит себе новые инструменты, а доктор вложится в самообучение.
> наверное тоже не против того, чтобы они попробовали что-то новое за ваш счёт?
И в этом случае не против. Потому что оплачиваться должна работа, а не потраченное на неё время. Программист соглашается выполнить определённую задачу за определённое время. Если программист выполнил задачу в два раза быстрее, то это не значит, что он должен получить за её выполнение в два раза меньше денег или делать в два раза больше задач. Это значит, что освободившееся время он имеет право тратить так, как захочет.
Значит текущий вызывает много боли и страдания. Либо потому что старый и кривой, либо потому что программист его не знает или вообще обладает низкой квалификацией. Главное отличить одно от другого
Автор рассматривает команду как группу единомышленников.
Мне кажется, что к этому и нужно стремиться. Иначе между сотрудниками возникает конкуренция, кто-то становится равнее остальных и всё в таком духе. Не знаю, подвержен ли этому абсолютно любой коллектив, но думаю, что единомыслие всё же более располагает к равноправию.
Инициатива? Творчество? Пффф… Я буду сидеть на попе ровно, пока PM не придет и не поставит мне чёткую задачу. Даже если в её формулировке будут проблемы — я никому ничего не скажу, ведь это проблемы PM-а, а не мои.
Вот это качество у 80% программистов идет из коробки. «Я программист, мое дело код писать, а дальше трава не расти. Закоммитил, работа выполнена...»
Но только если они проходят в уже слаженную команду. С нуля такой фокус не провернуть.
Это зависит не от позиционирования, а от того, является ли руководитель программистом. Если является — да, вокруг него может выстроиться нормальный рабочий процесс, куда вольются остальные. Если не является — то остается только искать нормальных кандидатов.
Ну согласитесь, что если программистами будет управлять SMM-щик, дизайнер или менеджер по рекламе, это неправильно, т.к. он не разбирается в специфике?
Хрестоматийный пример — это, конечно, Стивен Элоп, уничтовший на корню лидера рынка.
О хосподи, хрестоматийный пример — ваша безграмотность.
Я специально не буду рассматривать другие аспекты деятельности Элопа, такие как ранние обещания продуктов на WP, закрытия фабрик и т.д. Это и без меня много раз было обсосано и нового ничего я тут не скажу.Или другой, несомненно также вполне разумный, тезис:
С бюрократией и бизнес процессами, имеющимися на 2010 год, Нокиа не спас бы ни Андроид, ни половина населения Бангалора, пишущих на Qt под MeeGo.
Вина Элопа даже не в том, что он угробил Нокиа, а в том, что все его решения имели смысл только в разрере «да, мы уничтожим Нокиа, но спасём Microsoft» (чего, в общем, сделать тоже не удалось — мобильное направление Microsoft потерял).
Эта статья была бы черезвычайно ценна, полезна и, действительно, могла бы многое перевернуть в восприятии мира, если бы Элоп достиг таких же результатов, что и Герстнер (проблемы IBM и Nokia были, во многом, схожи). Однако случилось то, что случилось: подразделение, занимавшееся смартфонами, не имевшее до прихода Элопа ни одного убыточного квартала после реорганизации ни разу не принесло прибыли. До самого конца.
Плоблема в том, что Элопа, фактически, наняли для того, чтобы он аккуратно изменил стиль разработки и урезал бюрократию — как это сделал Луи. А он, вместо этого, решил всё «до основания разрушить» и… остаться у разбитого корыта. Для этого много ума не нужно, знаете ли.
Специфика безусловно влияет(причем обратно пропорционально масштабу проекта), но не более чем понимание предметной области программистом: хорошо бы если бы отельер с 20 годами опыта переквалифицировался и напедалил booking.com, он то ситуацию изнутри знает. Но в реальности оно бывает немного не так :)
Т.е. он всё равно так или иначе должен быть айтишником)
Аналитик, эксперт предметной области или заказчик не сможет обучить команду пользоваться тем же гитом.
Руководитель должен сделать так чтобы команда приняла решение использовать наиболее удобный для нее инструмент управления версиями. Но для этого ему не обязательно владеть хоть каким-то инструментом.
Ну и как команда примет наиболее удобный инструмент управления версиями если половина из них не знает что такое управление версиями, а другая половина поровну делится на фанатов git, mercurial, subversion, старого tfs, cvs и visual source safe?
Напомню, по условию в "команде" собрались случайные люди.
В каждой команде есть авторитеты — наиболее компетентные люди в своей области. Большая часть прислушивается к их мнению. Поэтому выберут гит и довольно быстро )
Напомню с чего началось обсуждение:
Но только если они проходят в уже слаженную команду. С нуля такой фокус не провернуть.
Откуда вы возьмете авторитетов в случайно собранной из случайных людей "команде"?
Это серьезный труд и внимание ему надо уделять на старте — всё, без остатка.
К тому же команды формируются не щелчком пальцев, а в течении продолжительного времени.
Тогда о чем вы спорите?
Хотя надо, конечно, отменить, что я — разбираюсь в производстве ПО.
К тому же команды формируются не щелчком пальцев, а в течении продолжительного времени.
В идеальном мире возможно.
Единственное, что остается делать профессионалам
Из вашего поста сквозит несколько откровенно нелепых утверждений, например «кто использует гит — тот профессионал», «кто не использует гит — тот не профессионал», «wintel — это плохо».
Вас кто-то обидел на работе, что ли? Кто вас укусил, разработчик Delphi, сидящий под SVN, или разработчик C++, сидящий под VSS?
Как уже замечено, новые люди либо принимают правила и становятся частью, либо отторгаются.
Получается, что это нежелание брать на себя ответственность, проявлять инициативу в надежде, что её проявит кто-то другой. Ведь тогда все шишки посыпятся на инициатора.
- Я работал в команде, а вы нет
- Ваша команда — не команда
- Вы находитесь на этапе провала
- Вам никогда не жить в прекрасном мире
- Я молодец ибо работал в команде и построил команду
- Вот вам пара банальных книг
Давайте по существу пост о том, как же вам удалось построить практически идеальную команду. Без банальных советов и литературы которую все и так уже читали.
Критиковать, задевать и выводить из себя здесь все умеют.
Тезисы примерно верны, но один вы упустили:
- Вот вам правила, взяв которые за основу, вы можете построить Команду.
Но считает свое мнение достаточно важным и авторитетным для того, чтобы постить стать на хабре.
Тезис 1. Программирование есть инженерия.
Тезис 2. За крайние 150 лет были наработаны вполне определенные практики управления большими коллективами инженеров, во многом идущие в разрез с опубликованными «рекомендациями».
Тезис 3. Все велосипедостроение процессов разработки характеризует состояние менеджмента во многих IT проектах. Впрочем в крупных проектах менеджеры вынуждены ставить нормальные процессы, и у меня складывается отчетливое впечатление, что ваши «рекомендации» идут исключительно от полного непонимания как организовывать работу средней команды в ~50 инженеров(приблизительно половина — девелоперы) на в проекте продолжительностью в пару лет.
Сходите в Tata Consulting и расскажите им что не надо решать за сотрудников как им работать
Ок, зачту.
Программирование есть инженерия.
Гениально!
За крайние 150 лет были наработаны вполне определенные практики
Ого! IT довольно особая область с особыми (избалованными) людьми. По-крайней мере что касается России. И управление в этой области, скажем так, на гребне волны. Так что ваш опыт 150летней давности, похоже, устарел.
работу средней команды в ~50
Да вы даже определение команды не удосужились посмотреть.
Посмотрите определение, а потом рекомендации по размеру. Команды размером 50 человек не бывает.
Но вы опять заговорили обо мне. В вашем комментарии нет ни одного утверждения, которое противоречило бы моей позиции, выраженной в статье. Печально.
IT довольно особая область с особыми (избалованными) людьми. По-крайней мере что касается России. И управление в этой области, скажем так, на гребне волны.
Над гребнем волны, где-то высоко и далеко. Избалованные люди, ценящие возможность выбрать какие задачи, какими инструментами и в какой последовательности они будут делать за счет заказчика — это не профессионалы.
Да вы даже определение команды не удосужились посмотреть.
Посмотрите определение, а потом рекомендации по размеру. Команды размеров 50 человек не бывает.
Над проектирвоанием А-380 трудились тысячи человек и они полностью соответствуют определению «команда» по первой ссылке. Естественно, чтобы управлять такой толпой была выстроена иерархия, как же без нее.
В вашем комментарии нет ни одного утверждения, которое противоречило бы моей позиции, выраженной в статье.
Я слишком ленив чтобы разбирать каждый тезис по частям, уж слишком они разнородные и сваленные в одну кучу без осмысления множества аспектов. Как то например интеграция разных команд, реиспользование кода в разных проектах, ротация сотрудников между проектами и соотвествующие эфорты на адаптацию и много других.
Над проектирвоанием А-380 трудились тысячи человек и они полностью соответствуют определению «команда» по первой ссылке. Естественно, чтобы управлять такой толпой была выстроена иерархия, как же без нее.А чем закончилась вся история — знаете или рассказать? Кончилось всё тем, что наступил полный коллапс, самолёт оснастить кабелями не удалось и сотни немецких инженеров пришлось отправлять в командировку во Францию, чтобы они там, на месте, решили-таки, чёрт побери, проблему.
Подозреваю что при этом образовалось вполне себе достаточно команд близких к тому, что описано в обсуждаемой статье — и, в конечном счёте, всё успешно разрешилось и самолёт успешно полетел. Убытки примерно в 6 миллиардов — плата за уверенность в том, что «150 лет наработанных практик == залог успеха».
Кончилось всё тем, что наступил полный коллапс, самолёт оснастить кабелями не удалось и сотни немецких инженеров пришлось отправлять в командировку во Францию, чтобы они там, на месте, решили-таки, чёрт побери, проблему.
А знаете в чем причина этой проблемы? Я процитирую вики:
На начальном этапе производство A380 было осложнено тем, что в каждом самолёте требовалось проложить 530 километров электропроводки. Airbus, в частности, ссылался на сложность прокладки проводки в кабине пилота (100 000 проводов и 40 300 соединительных), на то, что этот отдельный, параллельный проект должен удовлетворять требованиям каждой авиакомпании, на контроль за изменениями в конструкции и контроль за изменениями технической документации[19][20]. Немецкие и испанские заводы Airbus продолжали использование САПР CATIA версии 4, тогда как британские и французские перешли на CATIA версии 5. Это, по крайней мере частично, вызвало некоторые проблемы в области контроля за изменениями в конструкции, так как прокладка алюминиевых электропроводов требовала соблюдения специальных правил, включая использование нестандартных единиц измерения и радиусов
Тоесть банально начальник вовремя не помешал работать командам и волевым решением не внедрил одну версию САПРа. Спасибо за такой интересный пример «самоорганизиции команд», я про него сходу запамятовал.
Убытки примерно в 6 миллиардов — плата за уверенность в том, что «150 лет наработанных практик == залог успеха».
Ни разу не залог, многие инновационные проекты выходят за сроки и бюджеты, в том числе и благодаря косякм менеджмента. Но альтернативы иерархичному управлению в масштабе хотя бы 20 человек — нет.
Тоесть банально начальник вовремя не помешал работать командам и волевым решением не внедрил одну версию САПРа.Вы так говорите, как будто он мог «волевым решением» внедрить одну версию САПРа. Проблема в том, что консервативные немцы отказались переходить на новую версию, а «экспериментаторы» французы — перешли.
И тем всегда и кончаются ваши «150 лет практик»: так как люди не винтики, то они отказываются исполнять ваши «волевые решения» или саботируют их.
Если бы люди вели себя так, как сервера в кластере: «начальник послал приказ, все его приняли к сведению и через 5 секунд отчитались о выполнении», то ни о каких «командах» мы бы тут не говорили…
Но альтернативы иерархичному управлению в масштабе хотя бы 20 человек — нет.Наличие иерархии вовсе не обозначает, что «прямое» общение запрещено и не обозначает, что решения «спускаются сверху» без обсуждения…
Вы так говорите, как будто он мог «волевым решением» внедрить одну версию САПРа. Проблема в том, что консервативные немцы отказались переходить на новую версию, а «экспериментаторы» французы — перешли.
Вот как раз такие интеграционные решения обязаны и должны спускаться сверху и жестко контролироваться.
И, опуская дальнейшие цитаты, отмечу в очередной раз, вы мне приписываете какие то идеи из своей головы. Я нигде не писал что начальство обязано спускать и контролировать абсолютно все. Хороший менеджмент — это всегда баланс между крайностями, понимание того что можно отдать на откуп команде, а что «спустить сверху».
А вот
нельзя инженеру мешать творить то что он хочет, и как он хочет, даже если его понимание того что должно быть сделано отличается от того что нужно для бизнеса.
явный признак полного бедлама в процессе:
— инженер должен не «творить» а проектировать
— у «инженера», его коллег, менеджмента должно быть четкое и общее понимание целей и путей их достижение
— задачи должны быть поставлены и донесены четко и однозначно
— бизнес должен ставить задачи и принимать результат, отнюдь не диктовать имплементацию.
Это Миф. А программирование, точнее разработка ПО, уж извините, далеко не только инженерия.
Сергей, нет никакого SDLC который позволяет выдавать предсказуемый результат в оговоренные сроки с заранее запланированным качеством, бюджетом и с учетом рисков.
Есть. Иначе как минимум, сотни тысяч аутсорсеров-индусов крутили бы коровам хвосты, и это даже не вершина айсберга.
точнее разработка ПО, уж извините, далеко не только инженерия.
Не сомневаюсь, что у некоторых это «искусство», «творение» и так далее по шаблону своих братьев по духу, недоучек-гуманитариев. У них, кстате, постоянные проблемы со сроками, догадываешься почему?
Если есть — тогда почему ни A380 ни 787 не полетели в заранее запланированные сроки и их разработка не уложилась в бюджет?Сергей, нет никакого SDLC который позволяет выдавать предсказуемый результат в оговоренные сроки с заранее запланированным качеством, бюджетом и с учетом рисков.Есть.
A380 вы сами как пример привели, никто вас за язык не тянул.
Если есть — тогда почему ни A380 ни 787 не полетели в заранее запланированные сроки и их разработка не уложилась в бюджет?
Побуду кэпом. Риски в таких сложных и иновационных проектах несколько выше чем в типичном формоклепании. И некоторые из них обычно срабатывают, что вызывает отклонение от публично декларируемых сроков и и публично декларируемого бюджета. Какие сроки и бюджеты закладывали топ менеджеры А и Б на самом деле — я думаю мы врядле узнаем.
В современном мире обновления модных клауд сервисов и/или популярных Web сайтов поставляются на ежедневной основе.
И технологии и процессы разработки эволюционировали черезвычано сильно, но что осталось неизменным — это человеческая природа.
И конфликт внутри команды по прежнему может повлиять на сроки и бюджет сильнее чем любые технические риски.
Конфликты внутри команды — это банальные human factor риски, которые в инженерии вполне себе нормально митигируются уже десятки лет.
Кстате базовые инструменты митигирования этих рисков как то
— унификация всего чтоможно унифицировать
— максимально возможная независимость от «незаменимых» сотрудников
— разумное документирование
— ротация людей между командами
идут в разрез со многими из указанных в статье «советов».
Кстате базовые инструменты митигирования этих рисков как тоПриводят к тому, что Westinghouse и Areva так и не построили в XXI веке ни одного реактора, а Росатом — строит их «на потоке». Потому что Кириенко (да-да, «тот самый» Кириенко) в ответ на вопрос в чём причина успехов отвечает не задумавшись отвечает: "«Нам удалось сделать ГЛАВНОЕ: сохранить наших людей, наших Специалистов с большой буквы, преданных делу всей душой. Все остальное на фоне этого – вторично"
— унификация всего чтоможно унифицировать
— максимально возможная независимость от «незаменимых» сотрудников
— разумное документирование
— ротация людей между командами
Дело в том что митигируя «human factor» риски вы не получаете «высокую кухню». Если всё сделано правильно — вы получает «McDonalds» — конвеерное производство, порождающее много одинаково посредственного продукта.
А IT устроено так, что тиражировать даже самую дорогую вещь, в происзводство которой вложены миллиарды — можно почти бесплатно, потому потребность в Макдональдсах резко снижена.
А IT устроено так, что тиражировать даже самую дорогую вещь, в происзводство которой вложены миллиарды — можно почти бесплатно, потому потребность в Макдональдсах резко снижена.
Вы это Tata Consulting расскажите. Предварительно поинтересовавшись их операционными показателями.
А всякие гуглы с фейсбуками умудряются комбинировать «высокую кухню» со следованием корпоративным стандартам и буквально диктовке инженерам не только как им код писать, какому релиз циклу следовать, но и тому как им(например) публично высказывать свое отношение к гомосексуалистам. Смешные правда, не то что гордые фриланцыры?
Вы это Tata Consulting расскажите. Предварительно поинтересовавшись их операционными показателями.Поинтересовался. 385 тысяч сотрудников, 17.5 миллиардов выручки, меньше $50'000 в год на человека. Притом, что в McDonalds — 375 тысяч сотрудников, 24.6 миллиардов выручки.
То есть ваша Tata Counsulting — это, в буквальном смысле McDondalds — по всем показателям.
При этом тот же упомянутый вами Google — это 60'000 сотрудников, 90 миллиардов выручки, $1'500'00 на человека. Разницу ощущаете?
А всякие гуглы с фейсбуками умудряются комбинировать «высокую кухню» со следованием корпоративным стандартам и буквально диктовке инженерам не только как им код писать,Не путайте осознанное решение следовать принятым стандартам с их выработкой. Вот это вот — ну никак непохоже на «интеграционные решения обязаны и должны спускаться сверху», согласитесь? В конце-концов где, как вы думаете, описанная мною история произошла?
Как раз Facebook и Google — прекрасные примеры того, о чём говорится в статье: минимум решений принимается наверху, почти все предложения приходят «снизу». Но да, после того, как их обсудили и зафиксировали — они обязательны к исполнению.
но и тому как им(например) публично высказывать свое отношение к гомосексуалистам.Вы это всерьёз? Нет, правда? Это обычная американская зацикленность на политкорректности. К разработке отношения не имеет.
То есть ваша Tata Counsulting — это, в буквальном смысле McDondalds — по всем показателям.
Достаточно много аналогий прослеживается, особенно если в структуру доходов и расходов не вникать. Но делать из каких то поверхностных аналогий выводы, что Tata «хуже макдональдса» — это какой то треш. Прибыльность фирмы сравнима с прибыльностью IBM и Oracle.
Это тоже лузеры и неудачники, которые должны завидовать макдональдсу?
Вот это вот — ну никак непохоже на «интеграционные решения обязаны и должны спускаться сверху», согласитесь?
Где вы там интеграционные решения увидели?
А вот код конвенции таки спускаются сверху, не так ли?
Как раз Facebook и Google — прекрасные примеры того, о чём говорится в статье: минимум решений принимается наверху, почти все предложения приходят «снизу».
В статье говорится что наверху вообще не надо принимать решений:
Если вы решаете за сотрудников как им работать — вы не команда. Вы спускаете сверху git flow, список статусов задач, рабочие часы с 9:00 до 18:00? Похоже, вы упрощаете себе жизнь за счет того, что не пытаетесь найти правильное решение в конкретной ситуации? А может быть, чтобы отчитаться перед руководством о переходе на git flow? Оооо… да вы формалист. Только сама команда знает в каких условиях она может работать эффективно и только сама команда знает какие инструменты им нужны для работы. Если вы навязываете ваши правила против воли команды — вы не руководитель.
так что давайте не будем передергивать.
Где вы там интеграционные решения увидели?Конкретно там — их нету, это правда. Но вроде как в соотвествии со всеми «практиками» подобные вещи должны тоже «спускаться сверху», разве нет?
А вот код конвенции таки спускаются сверху, не так ли?По моим ссылкам как раз и были приведены обсуждения этого документа (вернее его соседа). Код конвенции утверждается «наверху» (хотя, на самом деле, нет — этим занимается не начальство, а эксперты по Java/C++/etc), но предожения принимаются от совершенно рядовых членов команды — и если они звучат разумно, то воплощаются в жизнь независимо от того, кто их высказал.
Ровно как в статье, которую мы обсуждаем, рекомендуют.
В статье говорится что наверху вообще не надо принимать решений:Серьёзно? Где?
Вы же сами привели цитату:
Если вы навязываете ваши правила против воли команды — вы не руководитель.А теперь фигнёй страдаете:
так что давайте не будем передергивать.Передёргиваете тут, в основном, вы. Стремясь утвердить в головах ложную дихотомию: либо руководитель «ломает всех об колено», либо он «вообще не принимает решений».
Хороший же рукодитель выступает, скорее, в качестве арбитра в спорных случаях. Если же наблюдается, более-менее, консенсус, то худшее, что может сделать руководитель — идти против всей команды. Я сам лично присутствовал пару раз на совещаниях где все присутствующие, кроме руководителя подразделения, были за одно решение, а он — за другое… разумеется был выбран вариант, который хотела команда. Если же мнения разделяются 50/50 — то тут нужно сначала попытаться одну из сторон сменить своё мнение, либо, на крайний случай, выбрать одно из решений и да, таки утвердить его.
Иногда этот подход работает — как вынужденное наименьшее зло. Но чем чаще вы его применяете, тем меньше вас будут слушать.
Конкретно там — их нету, это правда.
Ну так и не приводите мыльные треды с техническими обсуждениями в ответ на тезисы об интеграционных паттернах — а то получается вы что-то там сочинили и с блеском опровергли свои же сочинения.
Стремясь утвердить в головах ложную дихотомию: либо руководитель «ломает всех об колено», либо он «вообще не принимает решений».
Это делает автор статьи, я всего лишь его цитирую.
Иногда этот подход работает — как вынужденное наименьшее зло. Но чем чаще вы его применяете, тем меньше вас будут слушать.
Вот просто интересно. Сколько у вас лет работы на посте менеджера, сколько проектов вы сделали и каким кол-вом людей вы руководили?
Я ставлю на то, что ваш опыт даже меньше предполагаемого опыта автора статься(полгода-год из 12 лет фриланса, на прямой вопрос он не ответил).
Сколько у вас лет работы на посте менеджераНуль.
сколько проектов вы сделалиТочно не скажу, но в зависимости от того как считать (только крупные или все, только те, в которых я был техлидом или те, где техлидом был кто-то другой) — от трёх до пары десятков.
и каким кол-вом людей вы руководили?Максимум в моей команде было человек пять, ну так никто и не говорит, что в команде их должна быть тысяча. Любая команда, в которой более десятка человек — обычно разделяется на более мелкие компоненты (не обязательно жёстко, сейчас у нас в команде 6 человек, так что делить нечего, но на предыдущем месте их было где-то 20-25 и было, соответственно, 6 полунезависимых команд — но при этом некоторые люди входили сразу в несколько).
При этом под моим непосредственным менеджером до недавнего времени было 67 непосредственных «report»ов, так что у него просто физически не было времени на то, чтобы принимать технические решения — для этого техлиды есть.
Так что не нужно думать, что я тут описываю что-то, о чём я только в книжках читал, Ok?
Нуль.
Пожалуй с этого вопроса надо было начинать. Ну да ладно, лучше позже чем никогда.
Так что не нужно думать, что я тут описываю что-то, о чём я только в книжках читал, Ok?
Отчего же — вы вполне себе неплохо описываете типичные фантазии технаря про «этих мудаков менеджеров».
Но вам не хватает опыта с другой стороны баррикад. Наберетесь — перечитайте тред, уверен что найдете его забавным и может быть даже поучительным.
Засим откланиваюсь.
Отчего же — вы вполне себе неплохо описываете типичные фантазии технаря про «этих мудаков менеджеров».Кто вам сказал что я описываю фантазии, интересно? Подавляющее большинство компаний, где я работал не имели в штате ни одного менеджера — и ничего, продукты выпускались, продавались и так далее.
Но вам не хватает опыта с другой стороны баррикад.Я не очень понимаю зачем эти баррикады нужны, по большому счёту.
Менеджер выполняет роль смазки в двигателе. Но небольшой и хорошо организованный коллектив в ней не нуждается — как не нуждается в ней точно рассчитанный и качественно изготовленный керамический двигатель.
Конечно сделать двигатель на 10 мегаватт, работающий без смазки, не получится — и, начиная с какого-то масштаба, без менеджеров не обойтись.
Но так же, как и с двигателем — чем лучше у тебя «подогнаны детали», тем меньше требуется смазки и тем выше КПД.
Вот и всё.
IBM — это такой странный симбиоз. 90% компании — это такой же McDondalds, как и Tata, но есть ещё и IBM Research, который кардинально отличается от остальной части компании и ближе, скорее, к «гуглам с фейсбуками».То есть ваша Tata Counsulting — это, в буквальном смысле McDondalds — по всем показателям.Достаточно много аналогий прослеживается, особенно если в структуру доходов и расходов не вникать. Но делать из каких то поверхностных аналогий выводы, что Tata «хуже макдональдса» — это какой то треш. Прибыльность фирмы сравнима с прибыльностью IBM и Oracle.
Не знаю точно про Oracle, но подозреваю, что там — та же история.
Да и кто вам сказал, что я ненавижу McDondalds? Это — вполне успешное заведение. И людей, которые там проработали полгода-год и не «удавились на галстуке» я тоже уважаю. Но их подход — это не то, как нужно разрабатывать уникальный софт, вот и всё.
Это тоже лузеры и неудачники, которые должны завидовать макдональдсу?Нет, лузеры и неудачники — это люди, которые там работают десятилетиями. Пойти туда и отработать 3-5-7 лет, чтобы получить хоть какой-нибудь опыт? Нормально. Оставаться там работать на всю жизнь? Ну это как проработать 50 лет в McDondalds'е!
Но их подход — это не то, как нужно разрабатывать уникальный софт, вот и всё.
Это квитэссенция треда. Почему то каждый пионер уверен что он разрабатывает «уникальный софт»(тм), в команде «лучших профессионалов», а все остальные просто фигней страдают. Это иногда проходит, временами очень болезненно.
Почему то каждый пионер уверен что он разрабатывает «уникальный софт»(тм), в команде «лучших профессионалов», а все остальные просто фигней страдают.Даже работая в McDonalds'е стоит думать о том, как, всё-таки, делается нормальная еда. Если вы, конечно, хотите быть поваром, а не просто пришли в McDonalds за подработкой.
Потоковую потогонную систему, когда делается чёрт знает что чёрт знает зачем (потому что заказчик захотел) я тут не рассматриваю потому что за всё время работы я сталкивался с ней на протяжении, возможно, нескольких месяцев — и желания общаться с ней дальше у меня нет ровным счётом никакого. Как и у автора статьи.
Хм. Вы никогда не видели бизнес, который не умеет ставить задачи четко и однозначно? Вы никогда не видели исследовательских проектов? Серьезно?
Да, хоть какое-то понимание целей разумеется нужно, но в остальном вы слишком сильно обобщаете. Всякое бывает — и из этого следует, что нормальные процессы тоже бывают слегка разные.
Да, хоть какое-то понимание целей разумеется нужно, но в остальном вы слишком сильно обобщаете. Всякое бывает — и из этого следует, что нормальные процессы тоже бывают слегка разные.
Я думал, исходя из контекста статьи что мы тут говорим о коммерческой разработке софта за деньги. Безусловно, разные проекты требуют разных процессов, но при росте масштабов проектов и требованиях к повторяемости результата с разными сотрудниками, разные процессы начинают обретать одинаковые атрибуты, как то унифицированный процесс, унифицированный учет работ, унифицированная среда разработки, оценка и управление скоупом, рисками, промежуточный контроль выполнения и так далее по списку. Что не совсем хорошо согласуется с рекомендациями автора статьи, который кстате, тоже не отметил границы применимости своих рекомендаций.
Безусловно, разные проекты требуют разных процессов, но при росте масштабов проектов и требованиях к повторяемости результатаБолее нелепого утверждения я в жизни не видел. При росте мастабов проекта «требования к повторяемости» никак не могут расти. Просто потому, что это невозможно. Вы можете выйти на уровень, где вы можете успешно и в оговоренные сроки сделать что-нибудь в среднеразмерном проекте (ну, например, автоматизировать управление производством в цеху в 100-200 человек), если же вы делаете что-то реально крупное — то у вас неизбежно будут накладки и проблемы, которые все «150 лет практик» не разрешат и вам придётся полагаться на команды, подобные описанным в статье.
И неважно — разрабатываете вы самолёт или строите плотину, пишите операционку или движок для какой-либо игры. Если вы делаете что-то уникальное не очень похожее на аналоги (или если этих аналогов просто нет), то вам нужна команда, если вы что-то разрабатываете в 100500й раз, то достаточно «наработанных практик».
От масштаба зависит не так много, важна повторяемость процесса. И здесь программирование резко отличается от многих других дисциплин, так как во многие случаях то, что в других случаях потребует переделки и адаптации проекта (что, как раз, можно сделать используя «наработанные за 150 лет практики») в случае с софтом просто не нужно. Вы не будете возить почту из одной деревни с населенем в 100 человек в другую подобную же тем самым A380 — не окупится. Но можете взять движок, рассчитанный на миллионы посетитей — и ничего в нём не меняя разместить на нём бложик с посещением 100 человек в год.
Если вы делаете что-то уникальное не очень похожее на аналоги (или если этих аналогов просто нет), то вам нужна команда
Можно долго и нужно обсуждать ваш длинный и слабосвязанный пост, но давайте начнем с простого.
Вы и вправду думаете что автор статьи описывает решение каких-то уникальных, инновационных проблем программирования?
Ну так производитель оригинала снизит цену — и вы останетесь «на бобах». Себестоимость-то копии нулевая — сколько бы ни стоил оригинал!
99.99% всего промышленного девелопмента — это интеграция уже готовых кусков кода в нужной последовательности.
Думаю, тут очень кстати будет фраза из одного замечательного фильма: «Я хотя бы попробовал!». Человек высказал, в общем-то, дельные мысли, дискуссия таки завязалась :)
Я был свидетелем преобразования пропащей команды в хорошую -> набирать новую команду не обязательно.
1. Все дружно молчат. Что начальство, что остальные сотрудники. Когда я поднимаю тему составления плана выхода из сложившейся стагнации, никто должным образом не реагирует. Хотя уже бонусы не платят пол года и перспектив выхода никаких.
2. Работаем, как и положено, с 9 до 18, но при этом задач с гулькин нос. В основном, мелкая текучка. А там, кто чем занимается: народ смотрит фильмы, рисует, читает. Начальству вообще до лампочки.
3. Руководители появляются и уходят, как призраки. Ничего толкового не сообщают ни то, что отделу разработки, но и менеджерам.
4. Целеустремленность работников близка к 0. Стагнация уже больше года, и все становится только хуже. Народ думает, как свалить, но, естественно, все молчат.
5. Есть одно большое обещание от руководства, что скоро будет большой проект. И все будет хорошо. По этому проекту действительно ведутся переговоры. Но уже как пол года ни к чему не приводят.
Вот, что значит «эффективная команда».
Здравствуй автор, я тот чувак, который как раз и читает новелки на работе.
Ну для начала у нас на проекте действительно есть старая но сплоченная команда которая работает в месте 5 лет.
Да есть проблемы — вся команда бывает страдает фигней, при этом половина команды еще и жутко былокодит и велосипедит, даже я обычно пишу классный модуль kiss, SOLID, DDD по всем канонам с фабриками и DI но и этот код обрастает костылями из за которых мы получаем иногда очень веселые глюки. В этом хаосе я вижу множество причин.
- Бизнесу пофиг на технический долг, даже когда он ему прямо угрожает. Каждый лепит костыли на велосипедах и подпирает их костылями — я даже нарисовал костыльного монстра который должен придти и сожрать всех. Задачи на рефакторинг — в свободное время. Первое время я ими занимался час после работы, потом дома до полуночи и в итоге бывший студен стал женатым серьезным человеком и уже нет времени копаться в легаси дома в свободное время и без оплаты.
- Бизнес не знает чего хочет, на каждую задачу идет как минимум 10 итераций правок, с 10-50 правками на каждую итерацию. Самый сок — когда менеджеры с дизайнерами устраивают войну правок — мы запасаемся попкорном.
- Бизнес может заключить договор с парнерами, мусолить 2 месяца этот проект между собой, дать задачу сделать дизайн (не веб и не адаптивный) которую дизайнеры еще 2 недели делают и придти к нам в пн — мол в пятницу все должно быть готово. Естественно срок срывается и мы косячники а партнеры в ярости. Итог — дизайнеров мы притянули в наш отдел чтобы когда у них возникала новая задача мы уже начинали делать фронт и бэк по ней чтобы хоть как-то успевать.
- Если честно мотивировать нас сложно и нам самим сложно внедрять инновации. У меня ушло пол года чтобы заставить каждого из коллег поставить php-storm/idea ubuntu, локально развернуть nginx и 3 наиболее часто используемые на проектах версии php (5.4, 5.6, 7.1) и развернуть проекты локально с наиболее близкой к серверам конфигурациями, и заставить юзать git. Были еще предложения вроде визуализации, zabbix, закупки новых серверов, покупки bitbucket и jira. Но бизнес был глух — только когда наняли "крутого тимлида" со стороны он смог протолкнуть все это.
При этом команда все еще умудряется не развалиться. Несмотря на такой "хороший" менеджер, не ушла к конкурентам (причем были и те кто хотел взять сразу всю команду с +150% к окладу каждому а мне так вообще x3) находит способы раскидывать проекты сами и более менее дружна даже не смотря на то что мы перетираем коммиты друг друга. Сейчас все налаживается но все еще далеко от идеала. Но веры менеджерам нет — это раз, и напрягаться никто выше того за что нам платят не собирается так как менеджмент этого не видит.
Ну во первых было ломы это верно, во вторых та компания которая собиралась нас нанимать — разделила бы команду по разным отделам, и в третьих поковыряв знакомых мы нашли чувака из их конторы — у них такие же проблемы как у нас и при этом они уже наняли и распустили 2 команды до нас. Смысла идти в компанию которая путь и платит больше но уже разогнала 2 команды до нас — мы как-то не видели.
Есть контора А где мы там
- легаси, костыли и велосипеды
- проблемы с менеджерами
- нормальная оплата
- спокойная работа
- есть хорошая команда из 6 человек где я — middle php back, еще два middle frontend (jquery+nodejs+backbone) один php back+teamlead и еще два хороших таких fullstack студента которые с нами уже 3 года.
Есть контора Б которая предлагает работу и у них
- ушли 2-е команды разрабов (полностью весь штат)
- легаси, костыли и велосипеды
- 5 проектов по 1-2 человека на проект (нашу команду бы разделили на 5 команд)
- проблемы с менеджером
- высокий оклад и возможность получить акции компании
В итоге есть контора которая предлагает нам двойной и тройной оклад но работы у них больше и из за проблем с управлением проектами от них ушли две команды — знакомый из последней рассказал что там все плохо и есть проблемы с проектами и управлением. Плюс большая часть стэка куплена у москвичей и с ней есть проблемы. В итоге мы решили остаться при своихзнакомых костылях и велосипедах, плюс в текущей конторе hr поднял ставку в 1.5 раза. Решили остаться.
Мой дядя любит рассказывать байку про друга, "дважды еврея советского союза" (в смысле, уехал, а потом вернулся). Почему вернулся? Да там кругом одни евреи! Там, чтобы выжить, работать надо!
Я на таком упадническом настроении когда-то вообще ушёл из разработчиков. Это был интересный опыт. С трудом вернулся через восемь лет.
Бизнесу пофиг на технический долг, даже когда он ему прямо угрожает. Каждый лепит костыли на велосипедах и подпирает их костылями — я даже нарисовал костыльного монстра который должен придти и сожрать всех. Задачи на рефакторинг — в свободное время.
Мне всегда было странно, почему бизнес этого не понимает. Даже поговорка есть: поспешишь — людей насмешишь. То есть не всегда срабатывает быстрый говнокодинг для занятия какой-то ниши, так как потом так или иначе приходит пора допиливания и поддержки. А проект уже, оказывается, превратился в один большой big ball of mud
и настолько запутан, что выпуск новых фич занимает всё больше и больше времени.
Мне всегда было странно, почему бизнес этого не понимает.Классический эффект айсберга. Вот это вот:
Бизнес может заключить договор с парнерами, мусолить 2 месяца этот проект между собой, дать задачу сделать дизайн (не веб и не адаптивный) которую дизайнеры еще 2 недели делают и придти к нам в пн — мол в пятницу все должно быть готово.Проистекает из того, что они искренне считают, что раз дизайн в Photoshop нарисован — значит 90% дела сделано. Помните:
Люди, которые не являются программистами, смотрят на экран и видят какие-то пиксели. И если кажется, что эти пиксели могут собраться в программу, которая что-то делает, они думают «да ну, сколько там ещё осталось, чтобы она просто начала действительно работать?»Удивительным образом люди, способные это понять — не всегда бывшие программисты (хотя это помогает) и не всегда бывшие программисты способны это понять (вот это меня удивляет всегда больше всего).
В предельных случаях (когда бизнес не очень большой — скажем до 50-100 человек) можно обойтись и без него вообще.
А платить то кто будет? Это шедевр, распечатаю и повешу на стену. Сори, не удержался :)
Бухгалтерия, однако. Скорее всего — даже не входящая в штат компании.В предельных случаях (когда бизнес не очень большой — скажем до 50-100 человек) можно обойтись и без него вообще.А платить то кто будет?
Это шедевр, распечатаю и повешу на стену. Сори, не удержался :)Пожалуйста, мне не жалко.
Бухгалтерия, однако
Это еще один шедевр, очень кратко и однозначно идентифицирующий ваше понимание бизнеса.
В небольшом бизнесе на 50-100 человек внезапно появляется какая то отдельная от бизнеса бухгалтерия, готовая платить «за все» — это прекрасно, продолжайте в том же стиле :)
В небольшом бизнесе на 50-100 человек внезапно появляется какая то отдельная от бизнеса бухгалтерия, готовая платить «за все» — это прекрасно, продолжайте в том же стиле :)Знаете вас вопрос и мой ответ — это классическое: «а откуда деньги» — «из тумбочки».
Понятно, что даже если бизнес небольшой, то у него есть какие-то договора с кем-то и кто-то ему перечисляет какие-то деньги. Но когда у вас есть полдюжины или даже две дюжины работников, то никого, кроме владельца бизнеса, для решения вопроса «кому сколько заплатить» не нужно, а количество транзакций не окупает наличие отдельного бухгалтера на полную ставку. А менеджер себя окупает — но только если команду создать не удалось и люди вместе работают… плохо.
Зачем тут ещё какой-то менеджер и в чём будут состоять его обязанности — мне решительно непонятно.
И да — это не теоретические изыски, это то, как были устроены большинство компаний в которых я работал (да-да их была не одна и не две).
В части «brave new world» — лозунги («Наши действия подчинены общей цели» и т.п.)
Ощущение, что мне в очередной раз пытаются что-то продать.
Impact mapping. Gojko Adzic (не представляю как по-русски написатьГойко Аджич он:)
Сходите в Tata Consulting и расскажите им что не надо решать за сотрудников как им работать, поинтересовавшись предварительно ее макропоказателями.
Мне кажется выводы в статье как-то с потолка. "Идеал — вот так, плохо — вот так". Что с этим делать и какие могли быть причины? Почему это — хорошо, а вот это плохо?
Команда — это динамическое образование. У неё есть стадии развития, зависимость от корпоративной культуры, от цели. Для каждой корпоративной культуры и стадии развития понятие "идеальной" команды — разное. Описание идеала в статье прекрасно может подходит для "бирюзовых" компаний в которых большая часть сотрудников уже давно работает, но для какой-нибудь жесткой конкуретной компании "up or out" с хорошей текучкой это неприменимо вообще и с таким "идеалом" задачи IT подразделение выполнять не сможет.
В целом это всё хорошо расписано в книгах по регулярному менеджменту и командообразованию, а в статье зафиксирована только односторонняя позиция которая подается как общий идеал. Стоит добавить всё-таки в каких компаниях вы работали и в каких условиях для команды можно ориентироваться на эти положения.
Неловко будет, если выяснится, что все, что вы накропали — это фантазии на опыте мелкого аутсорсера из Томска, правда?
Я не стесняюсь показывать своё лицо, рассказывая свои мысли. А вы?
Владимир, на самом деле суть не в конкретных названиях компаний, а в том, что ваш опыт очень специфичен.
Давайте честно, если бы вы назвали козлом, например, (светлой памяти) Сегаловича, то было бы всем понятно, что козел именно вы. Вам кажется, что git flow спускают для того, чтобы отчитаться. Окей, это потому что вы не работали в серьезной разработке. Если вам кажется, что «правила разработки» — это заговор злых корпоративных зомби — посмотрите на документацию разработки ядра линукса, например. Она строже, чем во многих компаниях.
если бы вы назвали козлом
Суть не в том, чтобы назвать кого-то козлом, а в том чтобы сказать о проблеме, которая тебя беспокоит.
Вам кажется, что git flow спускают для того, чтобы отчитаться
Нет, мне так не кажется. Я уже ответил на подобный комментарий habrahabr.ru/post/337048/#comment_10396832
У меня складывается ощущение, что вы придираетесь к примерам, на которых я объяснял свою позицию, а не к самой позиции. Зачем? Примеры это просто красочные вымышленные ситуации.
«правила разработки» — это заговор злых корпоративных зомби
И опять мне так не кажется. А кажется мне, что команда сама сформирует правила работы и будет их яростно отстаивать.
сказать о проблеме, которая тебя беспокоит.
Тут ничего выдумывать не надо, надо следовать установленному процессу. Если у тебя кондиционер барахлит — звони по телефону 007 в хозслужбу. Если с жирой неполадки — пиши админам. Если есть что сказать по процессу разработки — назначай встречу со своим линейным менеджером. А вот директора козлом называть — неразумно и проблему не решает. Кстати, как вы думаете, откуда эти хорошие процессы берутся? Может быть их команда выдумывает?
Нет, мне так не кажется. Я уже ответил на подобный комментарий
Из-за вашей специфики у вас какой-то странный страх перед неким «насильственным внедрением». На самом деле внедрить процессы никого не насилуя — задача типичная для менеджера и хорошо описанная (хотя может быть в реальной жизни и не тривиальная).
Да, мой опыт действительно специфичен. В дальнейшем постараюсь обращать больше внимания описанию контекста.
Если вы решаете за сотрудников как им работать — вы не команда. Вы спускаете сверху git flow, список статусов задач, рабочие часы с 9:00 до 18:00?
Мой небольшой опыт показывает, что если кто-нибудь (необязательно РМ или начальство, просто кто-то, кому не все равно) не придумает, как организовывать работу (банально, конвенции по именованию файлов/директорий, конвенции по кодированию, rebase или merge и т.д.), то все будут делать это как попало. Если всех не приучить юзать git, то у кого-то вообще никакого версирования не будет, кто-то будет архивчики руками делать ежедневно, кто-то svn себе поставит. И код будет расползаться просто файлами по скайпу.
Возможно, если у вас уже есть настоящая команда, в которой все сознательные и рациональные люди, то они видят эту проблему и решают ее сообща, но в реальности таки придется некоторые вещи педалировать сверху, иначе будет просто помойка.
Отмечу, что у нас своя специфика, очень много небольших проектов, поэтому разработчикам существенно проще не контактировать друг с другом. Но тем не менее.
У нас даже просто сидящие в разных концах комнаты люди умудрялись развивать маленькие фабрики велосипедов, несовместимые друг с другом.
Ну да. Отсутствие или неполнота коммуникации и общепринятых стандартов в команде — рассадник решений «на коленке», причём повторенных у разных людей по-разному, грубо говоря, об одном и том же. Вы как-то с этим боретесь? Или это уже устоявшаяся практика?
Статья добротная. Но вот еще бы понять, как бороться с синдромом Not Invented Here
и с тем, что «нам некогда заниматься изучением чего-то там, нам надо писать код», сиюминутным исполнением задач без вдумчивого анализа и хватанием за голову впоследствии...
Если вы не знаете целей и интересов ваших сотрудников — вы не команда
От работодателя требуется лишь исправно платить зарплату. Еще не хватало, чтобы он в личную жизнь лез.
По второму пункту еще раз напишу, что нет противоречия между «выгодно для бизнеса» и «команда решает как работать». Точнее конфликт может быть, но лидеру нужно его разрешить. Иначе Команды не получится.
Интересы бизнеса говорят — сдать проект к такому-то числу с такими-то фичами, ибо конференция, контракт или что-то еще. А интересы команды говорят — надо перейти на другой фреймворк, все отрефакторить, все обвешать тестами и т.п. И угадайте кто чьими интересами должен проникнуться.
Да, существуют несколько корпораций в которых возможна такая командная работа и «свободная охота». Но для остальных это чистая страна эльфов, работать так как хочешь и над чем хочешь. Потому что бизнес и извлечение прибыли. Ну это если зарплата нужна, конечно. А в стартапе очень даже можно такую команду собрать, если инвестор богатый и добрый. Или если нет семьи с ипотекой…
интересы команды говорят — надо перейти на другой фреймворк
Это предположение.
Я вот другого мнения — все мы сидим на игле общественного одобрения. Все хотят быть полезными. Поэтому разработчик хочет сделать так чтобы бизнес им был доволен.
Интересы бизнеса говорят — сдать проект к такому-то числу с такими-то фичами, ибо конференция, контракт или что-то еще.Сиюминутные интересы. Исправление багов — денег стоит и разница между исправлением проблем на этапе дизайна и на этапе после внедрения — три порядка. Если у вас есть основания полагать что за 2-3 года (между разработкой и внедрением) ваша компания вырастет в тысячу раз — это может быть оправдано, иначе создание технического долга — иллюзия.
А интересы команды говорят — надо перейти на другой фреймворк, все отрефакторить, все обвешать тестами и т.п.Это те же самые интересы безнеса — только в будущем.
И угадайте кто чьими интересами должен проникнуться.А не нужно ничем «проникаться», нужно посчитать. Слева — сколько займёт внедрение нового фреймворка, справа — ожидаемый выигрыш. Не можете такого написать? Даже прикидок нет? А тогда с чего вы решили, что переход на новый фреймворк вообще имеет смысл?
Я бы сказал так, что хорошо, если команда понимает, что деньги сыпятся не с неба, а являются производной их труда. Вот тогда у них может появиться соответствующая мотивация. Казалось бы, очевидный тезис, но не все его принимают. Так как в идеале хочется делать интересные вещи и получать за это деньги. Тут понятно, что мотивация высокая и командная работа на высоте. А вот когда надо за деньги делать неинтересные вещи, тут мотивация падает. И часто это «перешагивание через голову» всей команды.
По поводу предложений: я могу принять решение по какому-либо вопросу, но интереснее и лучше когда это проходит обсуждение в коллективе, потому что могут быть высказаны улучшения или наоборот блокирующие факторы, которые одному человеку сложно сразу увидеть и осознать.
Делаю ежемесячные совещания отдела, хотя это не просто с нашей спецификой, на которых все рассказывают о своих выполненных задачах, планах, высказывают предложения, которые обсуждаются всеми.
Не надо так делать. Ничего хорошего в таких совещаниях нет и неизвестно. За всю свою жизнь ни разу не встречал коллективов, где бы подобные совещания чему-то способствовали. Либо таковые встречи заканчивались плачевно для коллектива/проекта/компании, либо прекращали быть (тоже плачевно для коллектива, потому что приводили к смене руководителя, а новый руководитель — он и есть новый руководитель).
План+ретроспектива — соглашусь;
обсудить — только при необходимости, каковая имеет место быть далеко не всегда.
А вот обсуждение планов и задач каждого — оно не только громоздко, оно нередко выливается в какое-нибудь громогласное непотребство, которое приходится пресекать руководителю.
Соответственно, такой сбор — оно уже совсем не совещание, а какая-нибудь планёрка минут на 5-15.
Разбираться с «непотребством», как вы высказались, и есть одна из задач руководителя
Спасибо за понимание. А то тут много чего понаписали про то, что руководитель не нужен. Либо о том, что команда вполне себе может решать задачи, которые обязан решать руководитель.
Про боль. По личному моему опыту начинать решение проблем всё-таки предпочтительнее с приватной беседы. Боль — она вполне себе может быть обусловлена личными причинами, озвучивать которые публично вполне себе может быть не совсем приемлемо.
И самое главное — когда появляется боль, требующая внимания руководителя, эту боль надо решать немедленно, а не на плановом совещании.
И второе. Я как-то вот так предпочитаю направлять свои усилия, чтобы исключить вероятность нештатных ситуаций, а не решать проблемы. Соответственно, комфортно себя чувствую только там, где руководители понимают, что предотвратить проблему существенно дешевле, нежели постоянно решать возникающие проблемы.
У нас в коллективе ежедневные планёрки — и ничего страшного. Как по мне, это наоборот помогает, когда проговариваешь, что делал вчера, что собираешься делать сегодня. Даже если планы в итоге нарушаются. По крайней мере, все более менее в курсе, что происходит с проектами.
Общая цель формулируется так, что учитывает цели каждого. Более или менее. Если есть человек, цель которого мешает достижению общей цели — он покидает команду.
т.е., если не получилось (не хватило опыта/знаний) завлечь человека своей целью, то он просто выкидывается. И до каких пор так? Пока не находится человек достаточно лояльный/«пластилиновый»/неуверенный или признаётся, что ты не руководитель и надо уходить самому?
Ведь очень удобный пункт, так можно увольнять всех подряд, не замечая, что проблема в руководителе…
Сударь, ваша команда — не команда