Комментарии 254
Интересный обзор, со многим согласен. Но чем git flow не угодил не совсем понятно.
С git flow всё в порядке, а вот насильное внедрение чего бы то ни было — не порядок.
Часто на проектах внедрения (1с) сталкивался с неприятием пользователей предлагаемой системы работы. К окончанию проекта делали повторный замер производительности (количества операций, оформленных документов, обслуженных посетителей, etc...). Чаще было в пользу системы и неприятие оказывалось деконструктивным.
Понятно, что творческий коллектив — это несколько иное (наверное), но это означает, что команда у нас есть :). Мы все приходим к 8-30 (начинаем работать в 9), уходим в 18-30 и позднее (офф — 18), видимо осознавая ценность дисциплины. И работа в выходные — не палочная, а по велению души.
Спасибо, что еще раз подтвердил, что у нас все относительно благополучно.
Понятно, что творческий коллектив — это несколько иное (наверное), но это означает, что команда у нас есть :). Мы все приходим к 8-30 (начинаем работать в 9), уходим в 18-30 и позднее (офф — 18), видимо осознавая ценность дисциплины. И работа в выходные — не палочная, а по велению души.
Спасибо, что еще раз подтвердил, что у нас все относительно благополучно.
осознавая
Вот! Это главное слово для строительства любой рабочей системы.
НЛО прилетело и опубликовало эту надпись здесь
Не знаю как коллеги, я часто на работе читаю статьи и книги. Тут сразу можно попробовать. Да и комфортнее, сдвоенный монитор против одиночного дома, плюс дома — это все таки близкие, которым тоже надо внимание уделить.
Хобби-проекты — да, причем пилим с коллегами. И были случаи, когда такой х-п (точнее полученные на нем навыки) дал возможность выиграть тендер.
Хобби-проекты — да, причем пилим с коллегами. И были случаи, когда такой х-п (точнее полученные на нем навыки) дал возможность выиграть тендер.
Вот, вы сейчас написали важную штуку «внедрение чего-либо». Порой кажется, что команде даже полезно иногда начинать работать с чем-то новым, чему-то учиться, несмотря на бугурт. Во-первых, создаётся минимально видимость того, что с ними кто-то работает, а, во-вторых, элиминируется болото, в котором могут засидеться люди.
Я согласен с тем, что необходимо постоянно что-то менять.
Видел интересную мысль на хабре по этому поводу. Своими словами могу сформулировать так: Правило одного нового. Команда делает или новый проект на известном стеке технологий, или команда делает типовой проект на новом стеке технологий.
Команда делает или новый проект на известном стеке технологий, или команда делает типовой проект на новом стеке технологий.Это не всегда удаётся. Но даже в этом случае полезно разделить команду на две — одна будет пилить новые технологии (если старые по каким-то причинам не подходят), другая — новый проект на старых (но консультируясь иногда с первой командой, чтобы в момент, когда новые технологии будут готовы не пришлось всё выкинуть к чертям собачьим).
Зависит от людей. Некоторых и пинать не надо, а другие только по указивке сверху шевельнутся освоить что-то новое, соответственно, если указивок нет, то и развития нет.
Не знаю, большинство проектов, что я видел, длятся годами. Типа какого-нибудь дропбокса, который сделали, и дальше только допиливают… Новые задачи разве что в стиле «переписать этот модуль» да «заменить тот». Плюс есть в команде люди с правом вето, у которых «Ну этой технологии всего 2 года, хз что из этого выйдет, не будем копаться в непроверенной хипстерской хрени» © почти цитата.
С git flow всё в порядке, а вот насильное внедрение чего бы то ни было — не порядок.
Взгляните со стороны менеджмента. Унификация процессов внутри компании это очень важно: можно легко перекинуть человека с одного проекта на другой и он в разумные сроки начнет давать результат. Во-вторых, упрощается администрирование: появляются шаблоны проектов, системные администраторы и dev ops начинают раворачитьвать рабочее окружение за часы, а не недели.
Это все чертовски важно. Ваш же подход программистко центричен, если так можно выразиться, а в компании обычно работают не только программисты, но и devops, тестировщики, внедренцы и т.д.
А теперь у вас продукт пишется четырьмя отделами/командами. Одна юзает git flow, другая просто git, третья mercurial, четвётрая svn. Потому что они лучше знают, что им удобнее. А как релиз выпускать… наймём пятую команду, пусть сами решают как собрать один релиз из нескольких реп. Правда, куча времени уйдёт на доведение релиза до рабочего состояния, т.к. компоненты всё время несовместимых версий оказываются. А руководитель продукта… а что руководитель, это не его дело решать в чём команде работать!
Или нет, давайте пусть весь проект будет в одной системе, пусть вся команда решит. Соберём все четыре отдела (40 человек) в большом митинг-руме и пусть выбирают что им удобнее. Заказчик пусть подождёт окончания холиворов. Руководитель… а что руководитель, это не его дело выбирать в чём команде работать!
[/sarcasm off]
Или нет, давайте пусть весь проект будет в одной системе, пусть вся команда решит. Соберём все четыре отдела (40 человек) в большом митинг-руме и пусть выбирают что им удобнее. Заказчик пусть подождёт окончания холиворов. Руководитель… а что руководитель, это не его дело выбирать в чём команде работать!
[/sarcasm off]
В большинстве случаев он все равно не выберет...
Затем предлагаю устроить митинги по выбору языка программирования, среды разработки, ишью трекера, системы документации, код конвенций, используемых библиотек-фреймворков, баз данных, архитектуры в конце концов…
А потом дадим слова тестировщикам — им тоже есть что обсудить и из чего выбрать.
А потом дадим слова тестировщикам — им тоже есть что обсудить и из чего выбрать.
Затем предлагаю устроить митинги по выбору языка программирования, среды разработки, ишью трекера, системы документации, код конвенций, используемых библиотек-фреймворков, баз данных, архитектуры в конце концов…Очень хорошее предложение. Без сарказма.
А потом дадим слова тестировщикам — им тоже есть что обсудить и из чего выбрать.
Есть одно но: слова «а мне нравится» может произносить только и исключительно руководитель (ведь зачем-то он таки нужен?) — а все остальные могут высказывать любые предложения по какому угодно поводу… но с цифрами в руках.
Вы не поверите насколько такое правило снижает накал дискуссий: все эти бесконечные споры, которые занимают годы обычно ведутся путём переливания «из пустого в порожнее» просто потому что обсуждаются какие-то абстрактные вещи, которые ни измерить, ни оценить невозможно.
Если подобные споры запретить — то окажется, что и у тестировщиков умные мысли встречаются. И гораздо чаще, чем вам кажется.
Оглянитесь вокруг. Народ десятилетиями аргументировано и с цифрами обсуждают проблемы табы&пробелы, виндовс&линукс, .NET&Java&C++&..., микросервисы&монолиты и так далее по списку: любая популярная проблема, не имеющая однозначного ответа просто обречена на бесконечный холивар.
И тоже самое будет на общем собрании при наличии некоторой критической массы увлеченного народа.
И тоже самое будет на общем собрании при наличии некоторой критической массы увлеченного народа.
Народ десятилетиями аргументировано и с цифрами обсуждают проблемы табы&пробелы, виндовс&линукс, .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.
А в чём преимущество гита перед меркуриалом?
В скорости. Если у вас «срез» проекта занимает не один десяток гигабайт, то элементарные операции с mercurial'ом начинают занимат ощутимое время. И оказывается что за то, чтобы операции происходили за секунды, а не за минуты люди готовы простить git'у очень и очень многое.
Я в своё время отказался от hg, т.к. тот не умел русские имена файлов под Windows. На заплатку FixUtf8 они забили… Похоже, воз и ныне там: WindowsUTF8Plan не обновлялся с середины 2014-го.
И они с этим справились! Хотя это и потребовало много времени, но зато все шероховатости были убраны
Я переведу на понятный: наш заказчик заплатил за неспешное образование и душевные переживания нашей команды.
Или так или платить за снижение мотивации работать. Программисту норму "15 гаек в час" не поставишь. Вроде работает, результат есть, а то, что его на 20% меньше, потому что его все бесит — не угадаешь
Еще как поставишь и KPI есть во всех крупных компаниях. Как только количество инженеров в проекте начинает измеряться десятками — моментально появляется статистика и соотвественно инструменты для измерения производительности каждого программиста.
Там и появляется «китайский» и «индусский» код. Я вас уверяю — фирмы, пишущие в 10'000 строк то, что можно написать в 100 не получают более дешёвого и качественного продукта — это иллюзия.
А причем тут «дешевый и качественный код», я про него где нить упоминал? Я говорил исключительно про повторяемость и гарантированность результата, что зачастую для бизнеса в сотни раз важнее чем дешевизна и качество.
Вот тут вы говорили про цену кода:
Я переведу на понятный: наш заказчик заплатил за неспешное образование и душевные переживания нашей команды.
Вы так ничего и не поняли. Заказчик платит за гарантию результата в сроки, что достигается отлаженным процессом с одной стороны, оплатой грамотного менеджмента — с другой.
Это вы не поняли, что грамотный менеджмент следит за мотивацией сотрудников, а не за KPI.
Вы все таки не понимаете, что мотивация сотрудников — это один из KPI.
И как же ее в таком случае измеряют? :-)
валом способов. Навскидку:
— кол-во эскалаций от сотрудников на менеджмент
— кол-во уволившихся-ротированных сотрудников
— рост зп(внезапно, если не сильно требуют, то низкий рост вместе с низкой ротацией — все довольны)
— удовлетворенность работой(опросники)
— «360 degree review»
Но это только вершина айсберга :)
— кол-во эскалаций от сотрудников на менеджмент
— кол-во уволившихся-ротированных сотрудников
— рост зп(внезапно, если не сильно требуют, то низкий рост вместе с низкой ротацией — все довольны)
— удовлетворенность работой(опросники)
— «360 degree review»
Но это только вершина айсберга :)
Допустим, ваши KPI работают и выявляют что программисты халтурят. Каковы действия идеального менеджера?
После этих действий программисты все еще халтурят. Каковы действия идеального менеджера?
После этих действий программисты научились обходить KPI, показывая хорошую мотивацию в опросах. Но проект так и не ускорился. Каковы действия идеального менеджера?
Всё вышеперечисленное имеет отношение к качеству менеджмента, а не KPI сотрудников.
НЛО прилетело и опубликовало эту надпись здесь
Это все интересно, но вырвано из контекста. Я его напомню. Диалог идет о том, как измерить мотивацию сотрудников.
А теперь 2 простых вопроса.
1. Является ли «моя мотивация» KPI сотрудника?
2. Является ли «мотивация подчиненных» KPI менеджера?
А теперь 2 простых вопроса.
1. Является ли «моя мотивация» KPI сотрудника?
2. Является ли «мотивация подчиненных» KPI менеджера?
Почему некоторые комментаторы ставят знак равенство между «команда решает как ей работать» и «полный бардак»? Вы, наверное, чертовски умные руководители, а работать вам приходится с идиотами? Или вы просто не знаете как поддерживать обсуждения? Вы думаете, что никто кроме вас не прислушивается к голосу разума? Как говорится, если вы общаетесь с дураком, то он скорее всего делает то же самое.
Потому что "команда решает, как ей работать" тождественно равно "бардак". Не всегда полный, но бардак гарантированный. Имею как жизненных (до ВУЗ-а), так и профессиональных примеров, когда команда "решала". Все (ВСЕ!) эти примерыр заканчивались плачевно, в лучшем случае — приглашением нового руководителя. Решатели плакали крокодильими слезами в таком случае. Есть примеров, когда команда дорешивалась до ликвидации компании, как самостоятельного лица (либо конкуренты покупали, либо банкротство, либо ещё что-нибудь такое "весёлое").
Решает ВСЕГДА руководитель. Он же и отвечает за принятые решения перед вышестоящим руководством и прочими инвесторами. И именно поэтому у руководителя з/п выше, чем у рядовых сотрудников. Члены же команды имеет право, а у хорошего руководителя, обязаны, сформулировать и предложить пожелания/требования к средствам и способам совместной работы. А руководитель, в свою очередь, обязан прислушаться к мнению своих подчинённых и выбрать наиболее соответствующие целям и задачам средства и способы.
А идеальным является руководитель, у которого в подчинении есть товарищи, у которых в договоре прописано разрешение публично объяснять руководителю глубину его некомпетентности не выбирая выражений. Я, правда, таких не встречал, к своему великому сожалению. :(
Потому что «команда решает, как ей работать» тождественно равно «бардак». Не всегда полный, но бардак гарантированныйАвторитарный руководитель точно также рано или поздно обеспечивает гарантированный бардак, посмотрите на опыт авторитарных правительств. Идеальная диктатура действительно гораздо эффективнее демократии, но беда в том, что идеальных диктаторов не бывает.
Есть примеров, когда команда дорешивалась до ликвидации компанииА примеров когда руководитель доводил до той же самой ликвидации вы не видели? Точно также есть примеры, когда компании с плоской структурой были вполне себе успешны.
Вы построили себе неопровержимую теорию — всегда должен быть авторитарный руководитель. Если это работает — теория хорошая. Если нет — все равно теория хорошая, просто руководитель был неправильный.
Не нужно бросаться в крайности. Бывают команды, где авторитарное правление дает положительные результаты, бывает наоборот.
Кто-то пострадал от «поэтов» в программировании, и пытается превратить его в армию, а кто-то наоборот, пострадал от диктаторов и пытается дать всем полную свободу. Советую обоим расширить свои взгляды. IT — это не армия, и не поэзия, оно где-то посередине.
Если решает всё и всегда руководитель (интересно, а что, по-вашему, он решает?), есть риск того, что ответственность и качество работы в команде будет снижаться и снижаться. Т.к. всё, что останется делать разработчикам, — выполнять указания сверху.
Если вы чего-то не видели значит этого нет? Ну так я видел команду, которая решала в том числе какие фичи надо запилить для того чтобы бизнесу было хорошо. И бизнес соглашался — потому что предложения были обоснованы. Так же как и команда принимала обоснованные решения бизнеса. И никакого бардака.
По моему истина где-то посередине. Приведу простой пример. Я работаю в конторе, где для работы над продуктом мы вынуждены были портировать код под нормальные архитектуры от wintel «команды». Эти лохи используют древнючие компиляторы из-за которых куча ненужных костылей в коде, и даже ими толком не умеют пользоваться, не используют систему контроля версий (точнее у них начальник использует VSS просто тупо складывая туда надерганные файлы от других разработчиков) в результате невозможно даже движение наших патчей критинизма назад и каждый новый релиз кода этих орлов это серьезная головная боль для всей цепочки. Это явная ситуация, где необходим принудительный перевод на git flow начала цепочки, принудительное соблюдение стандартов, стиля кодирования, изменение архитектуры, подхода к тестированию, релиз планов…
Довольно часто «эффективными менеджерами» осуществляются попытки внедрить в разработку какую-то технологию, которую они узнали 5 минут назад с хабра или кто-то знакомый рассказал. При этом начисто могут игнорироваться проблемы внедрения, категорическая бессмысленность этой технологии в текущем проекте или её «сырость».
Дело не в менеджерах. Программисты этим страдают не меньше. Особенно у них большая тяга переписать все на новый модный фреймворк. Это по всей видимости некая функция от природного любопытства и вера в магию.
Одно дело, когда врождённое любопытство и перфекционизм разработчика толкает на переписывание готового кода. Другое, когда сверху спускается необоснованное распоряжение из-за которого чуть ли не вся проделанная работа идёт псу под хвост. Что далеко ходить за примером. Проект, несколько лет работающих на MySql было приказано в сжатые сроки перевести на Postgre. Почему? Да просто один управленец прочитал где-то, что мускуль нынче не модно. И чёткие пацанчики поголовно используют только Postgre. Это ещё хорошо, что NoSql пока ещё не знаком этим товарищам.
Одно дело, когда врождённое любопытство и перфекционизм разработчика толкает на переписывание готового кода. Другое, когда сверху спускается необоснованное распоряжение из-за которого чуть ли не вся проделанная работа идёт псу под хвост.
Я все же думаю это одно и то же. Переписывание кода на новый фреймворк тоже пускает работу коту под хвост.
Как правило, инициатива разработчика обоснована и направлена на реализацию конкретных целей, которые призваны улучшить продукт. Тут я не учитываю действия разработчиков «не от мира сего», которые экспериментируют в продакшине.
Зачастую действия менеджеров, а в частности приведённый выше пример направлен исключительно на ИБД для начальства. А для проекта это сродни саботажу.
Зачастую действия менеджеров, а в частности приведённый выше пример направлен исключительно на ИБД для начальства. А для проекта это сродни саботажу.
Тут я должен оговориться, что я не против менеджеров, как таковых. Много вполне вменяемых ребят. Которые рулят разработкой и ведут команду за собой в вполне светлое будущее, прислушиваясь к мнению разработчиков. Основной негатив исключительно к самодурам, которые зная о технологиях в лучшем случае в теории ультимативно проталкивают свои «идеи» руководствуясь целью продемонстрировать свою полезность перед вышестоящим руководством.
Я не против вашей идеи, но вы плохих менеджеров-карьеристов почему-то сравниваете с хорошими программистами. Естественно такое сравнение не в пользу менеджеров.
Кстати, есть забавное наблюдение. Плохой менеджер или плохой программист может стать хорошим, при изменении контекста. Т.е. плохой/хороший является качеством не только самого человека.
И еще интересное наблюдение. Комплекты в diablo 2. Надел одну вещь — просто вещь. Надел вторую — получил +20 к урону молнией и сопротивление от ядов. Качества каждого человека в команде это его личные качества + влияние команды.
И еще интересное наблюдение. Комплекты в diablo 2. Надел одну вещь — просто вещь. Надел вторую — получил +20 к урону молнией и сопротивление от ядов. Качества каждого человека в команде это его личные качества + влияние команды.
Надо соблюдать баланс. Если программист не будет постоянно изучать новые технологии и расширять кругозор, есть риск остановки карьерного роста. А лучший способ изучить технологию — сделать что-нибудь с её использованием. А если ещё и за деньги работодателя, то вообще прекрасно.
Я стесняюсь спросить, а вы когда нанимаете кого-то на работу (допустим сантехник, электрик, доктор...) наверное тоже не против того, чтобы они попробовали что-то новое за ваш счёт?
Этого противоречия может и не быть, если руководителю выгоден рост профессионализма сотрудников и внедрение новых технологий.
Кстати, неверная аналогия у вас. Сантехнику за «что-то новое» платит компания, в которой он работает, а не конечный заказчик. Если сантехник работает сам на себя, то и платит за «что-то новое» он сам. Так же как и разработчики-фрилансеры.
Кстати, неверная аналогия у вас. Сантехнику за «что-то новое» платит компания, в которой он работает, а не конечный заказчик. Если сантехник работает сам на себя, то и платит за «что-то новое» он сам. Так же как и разработчики-фрилансеры.
Наверное скапитаню, но всё-таки заказчик всегда платит и за услуги, и за «что-то новое»
Хоть сантехнику на зарплате, хоть фрилансеру
Только это происходит неявно — никому и в голову не придёт сказать клиенту «я тут решил поэкспериментировать за ваш счёт, гоните бабки» (если, конечно, это не учёные)
Просто расходы на развитие в виде обучения и экспериментов включены в счета за работу и раскиданы по всем клиентам
Хоть сантехнику на зарплате, хоть фрилансеру
Только это происходит неявно — никому и в голову не придёт сказать клиенту «я тут решил поэкспериментировать за ваш счёт, гоните бабки» (если, конечно, это не учёные)
Просто расходы на развитие в виде обучения и экспериментов включены в счета за работу и раскиданы по всем клиентам
В случае сантехников, электриков аналогом является вложение в оборудование и инструменты, в случае докторов — какие-нибудь дополнительные курсы. Ну а программист работает мозгами — мозги и нужно развивать.
Если я кого-то нанимаю, то значит, качество и цена меня полностью устраивает. И я совершенно не буду возражать, если сантехник на эти деньги купит себе новые инструменты, а доктор вложится в самообучение.
> наверное тоже не против того, чтобы они попробовали что-то новое за ваш счёт?
И в этом случае не против. Потому что оплачиваться должна работа, а не потраченное на неё время. Программист соглашается выполнить определённую задачу за определённое время. Если программист выполнил задачу в два раза быстрее, то это не значит, что он должен получить за её выполнение в два раза меньше денег или делать в два раза больше задач. Это значит, что освободившееся время он имеет право тратить так, как захочет.
Если я кого-то нанимаю, то значит, качество и цена меня полностью устраивает. И я совершенно не буду возражать, если сантехник на эти деньги купит себе новые инструменты, а доктор вложится в самообучение.
> наверное тоже не против того, чтобы они попробовали что-то новое за ваш счёт?
И в этом случае не против. Потому что оплачиваться должна работа, а не потраченное на неё время. Программист соглашается выполнить определённую задачу за определённое время. Если программист выполнил задачу в два раза быстрее, то это не значит, что он должен получить за её выполнение в два раза меньше денег или делать в два раза больше задач. Это значит, что освободившееся время он имеет право тратить так, как захочет.
Значит текущий вызывает много боли и страдания. Либо потому что старый и кривой, либо потому что программист его не знает или вообще обладает низкой квалификацией. Главное отличить одно от другого
А я наоборот, не согласен. Автор рассматривает команду как группу единомышленников. А это не всегда так. В общем случае команда — это коллектив, где каждый знает свои функции и выполняет их. Этого можно успешно достичь разными способами, и дружеским пониманием, и административным управлением. И в обоих случаях ключевую роль играет не сам способ, а люди. Если они профессионально делают своё дело, команда будет работать. Если нет, то не будет.
Автор рассматривает команду как группу единомышленников.
Мне кажется, что к этому и нужно стремиться. Иначе между сотрудниками возникает конкуренция, кто-то становится равнее остальных и всё в таком духе. Не знаю, подвержен ли этому абсолютно любой коллектив, но думаю, что единомыслие всё же более располагает к равноправию.
Для себя открыл пока что сделал один вывод: Команду невозможно построить из произвольно взятых людей. Чтобы собрать настоящую команду из 10 человек, для начала нужно перелопатить сотни кандидатов.
Вот это качество у 80% программистов идет из коробки. «Я программист, мое дело код писать, а дальше трава не расти. Закоммитил, работа выполнена...»
Инициатива? Творчество? Пффф… Я буду сидеть на попе ровно, пока PM не придет и не поставит мне чёткую задачу. Даже если в её формулировке будут проблемы — я никому ничего не скажу, ведь это проблемы PM-а, а не мои.
Вот это качество у 80% программистов идет из коробки. «Я программист, мое дело код писать, а дальше трава не расти. Закоммитил, работа выполнена...»
Прикол в том, что когда даже не совсем подходящие кадры приходят в слаженную команду — они принимают правила игры и вливаются.
Но только если они проходят в уже слаженную команду. С нуля такой фокус не провернуть.
Смотря как позиционировать руководителя. Если он является частью команды, то с нуля и не придется.
Это зависит не от позиционирования, а от того, является ли руководитель программистом. Если является — да, вокруг него может выстроиться нормальный рабочий процесс, куда вольются остальные. Если не является — то остается только искать нормальных кандидатов.
Вы наверное не знаете старой доброй поговорки «сделать плохого менеджера из хорошего программиста»? Дык вот, она не на пустом месте появилась.
Ну согласитесь, что если программистами будет управлять SMM-щик, дизайнер или менеджер по рекламе, это неправильно, т.к. он не разбирается в специфике?
От человека зависит больше, чем от его профессии. Когда мне говорят что IT'шниками должен управлять только IT'шник я всегда вспоминаю Луи Герстнера — «человека, который спас IBM». Пришедший в IBM из RJR Nabisco, которая занималась расфасовкой продуктов (sic!) — а потом вспоминаю про бесчисленных «финансовых гениев», которые сменили «необученных профессионалов» и в результате ввели свою компанию в убытки. Хрестоматийный пример — это, конечно, Стивен Элоп, уничтовший на корню лидера рынка.
Хрестоматийный пример — это, конечно, Стивен Элоп, уничтовший на корню лидера рынка.
О хосподи, хрестоматийный пример — ваша безграмотность.
А что я должен был прочитать по ссылке, интересно? Ключевой момент, что ли:
Вина Элопа даже не в том, что он угробил Нокиа, а в том, что все его решения имели смысл только в разрере «да, мы уничтожим Нокиа, но спасём Microsoft» (чего, в общем, сделать тоже не удалось — мобильное направление Microsoft потерял).
Эта статья была бы черезвычайно ценна, полезна и, действительно, могла бы многое перевернуть в восприятии мира, если бы Элоп достиг таких же результатов, что и Герстнер (проблемы IBM и Nokia были, во многом, схожи). Однако случилось то, что случилось: подразделение, занимавшееся смартфонами, не имевшее до прихода Элопа ни одного убыточного квартала после реорганизации ни разу не принесло прибыли. До самого конца.
Плоблема в том, что Элопа, фактически, наняли для того, чтобы он аккуратно изменил стиль разработки и урезал бюрократию — как это сделал Луи. А он, вместо этого, решил всё «до основания разрушить» и… остаться у разбитого корыта. Для этого много ума не нужно, знаете ли.
Я специально не буду рассматривать другие аспекты деятельности Элопа, такие как ранние обещания продуктов на WP, закрытия фабрик и т.д. Это и без меня много раз было обсосано и нового ничего я тут не скажу.Или другой, несомненно также вполне разумный, тезис:
С бюрократией и бизнес процессами, имеющимися на 2010 год, Нокиа не спас бы ни Андроид, ни половина населения Бангалора, пишущих на Qt под MeeGo.
Вина Элопа даже не в том, что он угробил Нокиа, а в том, что все его решения имели смысл только в разрере «да, мы уничтожим Нокиа, но спасём Microsoft» (чего, в общем, сделать тоже не удалось — мобильное направление Microsoft потерял).
Эта статья была бы черезвычайно ценна, полезна и, действительно, могла бы многое перевернуть в восприятии мира, если бы Элоп достиг таких же результатов, что и Герстнер (проблемы IBM и Nokia были, во многом, схожи). Однако случилось то, что случилось: подразделение, занимавшееся смартфонами, не имевшее до прихода Элопа ни одного убыточного квартала после реорганизации ни разу не принесло прибыли. До самого конца.
Плоблема в том, что Элопа, фактически, наняли для того, чтобы он аккуратно изменил стиль разработки и урезал бюрократию — как это сделал Луи. А он, вместо этого, решил всё «до основания разрушить» и… остаться у разбитого корыта. Для этого много ума не нужно, знаете ли.
Согласен. Каждый должен заниматься своим делом. Управление проектами — это специальность, которой 5 лет учат в вузе(в пост советских — плохо учат), а не тягание квадратиков в жире, как многие думают и как зачастую это бывает в реальной жизне, увы.
Специфика безусловно влияет(причем обратно пропорционально масштабу проекта), но не более чем понимание предметной области программистом: хорошо бы если бы отельер с 20 годами опыта переквалифицировался и напедалил booking.com, он то ситуацию изнутри знает. Но в реальности оно бывает немного не так :)
Специфика безусловно влияет(причем обратно пропорционально масштабу проекта), но не более чем понимание предметной области программистом: хорошо бы если бы отельер с 20 годами опыта переквалифицировался и напедалил booking.com, он то ситуацию изнутри знает. Но в реальности оно бывает немного не так :)
Не обязательно программистом. Может быть аналитиком или тестеровщиком. Вариантов масса.
Т.е. он всё равно так или иначе должен быть айтишником)
Я не могу этого утверждать. Бизнес аналитик еще может быть. Или эксперт из предметной области. Заказчик, в конце концов.
Аналитик, эксперт предметной области или заказчик не сможет обучить команду пользоваться тем же гитом.
Руководитель не должен да и просто не может быть самым опытным в каждом аспекте производства ПО.
Руководитель должен сделать так чтобы команда приняла решение использовать наиболее удобный для нее инструмент управления версиями. Но для этого ему не обязательно владеть хоть каким-то инструментом.
Руководитель должен сделать так чтобы команда приняла решение использовать наиболее удобный для нее инструмент управления версиями. Но для этого ему не обязательно владеть хоть каким-то инструментом.
Ну и как команда примет наиболее удобный инструмент управления версиями если половина из них не знает что такое управление версиями, а другая половина поровну делится на фанатов git, mercurial, subversion, старого tfs, cvs и visual source safe?
Напомню, по условию в "команде" собрались случайные люди.
Ну прям, вот повезло, ситуация )
В каждой команде есть авторитеты — наиболее компетентные люди в своей области. Большая часть прислушивается к их мнению. Поэтому выберут гит и довольно быстро )
В каждой команде есть авторитеты — наиболее компетентные люди в своей области. Большая часть прислушивается к их мнению. Поэтому выберут гит и довольно быстро )
Напомню с чего началось обсуждение:
Но только если они проходят в уже слаженную команду. С нуля такой фокус не провернуть.
Откуда вы возьмете авторитетов в случайно собранной из случайных людей "команде"?
Не надо случайным образом собирать команды :)
Это серьезный труд и внимание ему надо уделять на старте — всё, без остатка.
К тому же команды формируются не щелчком пальцев, а в течении продолжительного времени.
Это серьезный труд и внимание ему надо уделять на старте — всё, без остатка.
К тому же команды формируются не щелчком пальцев, а в течении продолжительного времени.
Тогда о чем вы спорите?
Я утверждаю, что «такой фокус провернуть» можно, даже если в команде есть только один руководитель, не разбирающийся в производстве ПО. Потому что очень естественно принимать правила игры того места куда ты приходишь. Ну, а если правила категорически не принимаются — значит придётся искать другого сотрудника. Не знаю, может у меня талант, но правила командной игры я всегда распространял в коллективе, за который нёс ответственность, достаточно легко. Даже когда набирал команду с нуля.
Хотя надо, конечно, отменить, что я — разбираюсь в производстве ПО.
Хотя надо, конечно, отменить, что я — разбираюсь в производстве ПО.
К тому же команды формируются не щелчком пальцев, а в течении продолжительного времени.
В идеальном мире возможно.
Практика показывает, что в больших командах, особенно с большой wintel частью не выберут и не быстро и git тут лишь верхушка айсберга. Единственное, что остается делать профессионалам так это медленно и планомерно создать невыносимые условия для неэффективных подходов и простые и легкие для эффективных.
Единственное, что остается делать профессионалам
Из вашего поста сквозит несколько откровенно нелепых утверждений, например «кто использует гит — тот профессионал», «кто не использует гит — тот не профессионал», «wintel — это плохо».
Вас кто-то обидел на работе, что ли? Кто вас укусил, разработчик Delphi, сидящий под SVN, или разработчик C++, сидящий под VSS?
Команда кристаллизуется вокруг решения общей проблемы и с учётом человеческих взаимоотношений. А не специальным образом соответствующими кадрами.
Как уже замечено, новые люди либо принимают правила и становятся частью, либо отторгаются.
Как уже замечено, новые люди либо принимают правила и становятся частью, либо отторгаются.
Получается, что это нежелание брать на себя ответственность, проявлять инициативу в надежде, что её проявит кто-то другой. Ведь тогда все шишки посыпятся на инициатора.
НЛО прилетело и опубликовало эту надпись здесь
Какая-то безапелляционная и снисходительная манера подачи… Сколько людей, столько и команд — идеала нет, от слова совсем (советы, типа: «радуйтесь», бесят). В каждой системе есть полезные концепции, есть не очень, есть смешные. Считаете что вам повезло: бывает… хотя, может вам просто хотелось саморекламы?
Рад, что я вас задел. Это была одна из целей. Но давайте по существу.
imho, основные тезисы статьи:
Давайте по существу пост о том, как же вам удалось построить практически идеальную команду. Без банальных советов и литературы которую все и так уже читали.
Критиковать, задевать и выводить из себя здесь все умеют.
- Я работал в команде, а вы нет
- Ваша команда — не команда
- Вы находитесь на этапе провала
- Вам никогда не жить в прекрасном мире
- Я молодец ибо работал в команде и построил команду
- Вот вам пара банальных книг
Давайте по существу пост о том, как же вам удалось построить практически идеальную команду. Без банальных советов и литературы которую все и так уже читали.
Критиковать, задевать и выводить из себя здесь все умеют.
Тут нет секрета: вырабатываешь правила и придерживаешься их. Правила примерно описаны в разделе «Ваша команда — не команда». А команда подхватывает, если, конечно, совсем неподходящего человека не нанял, скажем, индивидуалиста, который не способен слышать мнения окружающих.
Тезисы примерно верны, но один вы упустили:
Тезисы примерно верны, но один вы упустили:
- Вот вам правила, взяв которые за основу, вы можете построить Команду.
Самое забавное то, что судя по введению, аффтар и в командах толком не работал, и с проектами средней продолжительности не сталкивался, не говоря уже о саппорте: за 12 лет опыта аж 2 раза работал в команде и сменил «около 10» мест работы — смена места работы — раз в год.
Но считает свое мнение достаточно важным и авторитетным для того, чтобы постить стать на хабре.
Но считает свое мнение достаточно важным и авторитетным для того, чтобы постить стать на хабре.
Среднее значение не всегда отражает реальную картину. Может быть два раза по пять лет и восемь раз по три месяца.
Это возможно. Могу разве что попросить топикстартера дать больше инфы о своем опыте: продолжительность проектов, размеры команд, количество команд работающих над одним солюшнем…
Да, скорее всего, сделаю это позже. Пока еще не пришло время.
Опять какой то детский сад и тайны мадридского двора.
Перечитал ваши комментарии и обнаружил, что не было ни одного по существу. Все обо мне. Приглашаю вас почитать мои будущие статьи — возможно, я заинтересую вас еще больше.
Плохо читаете. Ну да ладно, напишу прямым текстом, мне не жалко.
Тезис 1. Программирование есть инженерия.
Тезис 2. За крайние 150 лет были наработаны вполне определенные практики управления большими коллективами инженеров, во многом идущие в разрез с опубликованными «рекомендациями».
Тезис 3. Все велосипедостроение процессов разработки характеризует состояние менеджмента во многих IT проектах. Впрочем в крупных проектах менеджеры вынуждены ставить нормальные процессы, и у меня складывается отчетливое впечатление, что ваши «рекомендации» идут исключительно от полного непонимания как организовывать работу средней команды в ~50 инженеров(приблизительно половина — девелоперы) на в проекте продолжительностью в пару лет.
Тезис 1. Программирование есть инженерия.
Тезис 2. За крайние 150 лет были наработаны вполне определенные практики управления большими коллективами инженеров, во многом идущие в разрез с опубликованными «рекомендациями».
Тезис 3. Все велосипедостроение процессов разработки характеризует состояние менеджмента во многих IT проектах. Впрочем в крупных проектах менеджеры вынуждены ставить нормальные процессы, и у меня складывается отчетливое впечатление, что ваши «рекомендации» идут исключительно от полного непонимания как организовывать работу средней команды в ~50 инженеров(приблизительно половина — девелоперы) на в проекте продолжительностью в пару лет.
Перечитал комментарии еще раз. Действительно один комментарий по делу:
Ок, зачту.
Гениально!
Ого! IT довольно особая область с особыми (избалованными) людьми. По-крайней мере что касается России. И управление в этой области, скажем так, на гребне волны. Так что ваш опыт 150летней давности, похоже, устарел.
Да вы даже определение команды не удосужились посмотреть.
Посмотрите определение, а потом рекомендации по размеру. Команды размером 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 человек — нет.Наличие иерархии вовсе не обозначает, что «прямое» общение запрещено и не обозначает, что решения «спускаются сверху» без обсуждения…
Вы так говорите, как будто он мог «волевым решением» внедрить одну версию САПРа. Проблема в том, что консервативные немцы отказались переходить на новую версию, а «экспериментаторы» французы — перешли.
Вот как раз такие интеграционные решения обязаны и должны спускаться сверху и жестко контролироваться.
И, опуская дальнейшие цитаты, отмечу в очередной раз, вы мне приписываете какие то идеи из своей головы. Я нигде не писал что начальство обязано спускать и контролировать абсолютно все. Хороший менеджмент — это всегда баланс между крайностями, понимание того что можно отдать на откуп команде, а что «спустить сверху».
Интересно что термин «нормальные процессы», я впервые услышал чуть больше 20 лет назад и с тех пор слышал великое разнообразие определений от различных инженеров как именно они должны выглядеть. За 20 лет они довольно сильно эволюционировали и крайне трудно между ними выбрать что-то общее, разве только то, что нельзя инженеру мешать творить то что он хочет, и как он хочет, даже если его понимание того что должно быть сделано отличается от того что нужно для бизнеса.
Нормальный процесс — это SDLC процесс позволяющий выдавать предсказуемый результат в оговоренный срок с заранее запланированным уровнем качества, с учетом рисков.
А вот
явный признак полного бедлама в процессе:
— инженер должен не «творить» а проектировать
— у «инженера», его коллег, менеджмента должно быть четкое и общее понимание целей и путей их достижение
— задачи должны быть поставлены и донесены четко и однозначно
— бизнес должен ставить задачи и принимать результат, отнюдь не диктовать имплементацию.
А вот
нельзя инженеру мешать творить то что он хочет, и как он хочет, даже если его понимание того что должно быть сделано отличается от того что нужно для бизнеса.
явный признак полного бедлама в процессе:
— инженер должен не «творить» а проектировать
— у «инженера», его коллег, менеджмента должно быть четкое и общее понимание целей и путей их достижение
— задачи должны быть поставлены и донесены четко и однозначно
— бизнес должен ставить задачи и принимать результат, отнюдь не диктовать имплементацию.
Сергей, нет никакого SDLC который позволяет выдавать предсказуемый результат в оговоренные сроки с заранее запланированным качеством, бюджетом и с учетом рисков.
Это Миф. А программирование, точнее разработка ПО, уж извините, далеко не только инженерия.
Это Миф. А программирование, точнее разработка ПО, уж извините, далеко не только инженерия.
Сергей, нет никакого SDLC который позволяет выдавать предсказуемый результат в оговоренные сроки с заранее запланированным качеством, бюджетом и с учетом рисков.
Есть. Иначе как минимум, сотни тысяч аутсорсеров-индусов крутили бы коровам хвосты, и это даже не вершина айсберга.
точнее разработка ПО, уж извините, далеко не только инженерия.
Не сомневаюсь, что у некоторых это «искусство», «творение» и так далее по шаблону своих братьев по духу, недоучек-гуманитариев. У них, кстате, постоянные проблемы со сроками, догадываешься почему?
Истина где-то посередине. Действительно есть ряд проектов где можно выдать предсказуемый результат и сроки, и в них «творцы» очень часто наносят ущерб. С другой стороны есть немало проектов, где в основе лежит только идея, а требования могут меняться чуть ли не каждый день. И тут, несмотря на то, что это остается инженерией, очень сложно предоставить большую предсказуемость. Собственно на этой основе и появилась потребность в гибких методология.
Дык вся неопределенность выносится на уровень менеджмента. Программист все так же рутинно открывает ишью трекер, читает стори, эстимирует, педалит, перевешивает сторю на тестировщиков. А менеджмент беклога, который становится коротким и непредсказуемым — это уже к лидам и менеджерам, инженерии тут(почти) нет, равно как от инженера не требуется ничего кроме инженерии(возможно — лучшая квалификация чтобы поддерживать codebase во вменяемом состоянии при бардаке с требованиями).
Если есть — тогда почему ни A380 ни 787 не полетели в заранее запланированные сроки и их разработка не уложилась в бюджет?Сергей, нет никакого SDLC который позволяет выдавать предсказуемый результат в оговоренные сроки с заранее запланированным качеством, бюджетом и с учетом рисков.Есть.
A380 вы сами как пример привели, никто вас за язык не тянул.
Если есть — тогда почему ни A380 ни 787 не полетели в заранее запланированные сроки и их разработка не уложилась в бюджет?
Побуду кэпом. Риски в таких сложных и иновационных проектах несколько выше чем в типичном формоклепании. И некоторые из них обычно срабатывают, что вызывает отклонение от публично декларируемых сроков и и публично декларируемого бюджета. Какие сроки и бюджеты закладывали топ менеджеры А и Б на самом деле — я думаю мы врядле узнаем.
Ммм, вы меня не поняли Сергей, 20 лет назад комерческие продукты поставлялись на CD, или даже на магнитных дискетах. И цикл разработки нового релиза длительностью 5 лет был нормой.
В современном мире обновления модных клауд сервисов и/или популярных Web сайтов поставляются на ежедневной основе.
И технологии и процессы разработки эволюционировали черезвычано сильно, но что осталось неизменным — это человеческая природа.
И конфликт внутри команды по прежнему может повлиять на сроки и бюджет сильнее чем любые технические риски.
В современном мире обновления модных клауд сервисов и/или популярных Web сайтов поставляются на ежедневной основе.
И технологии и процессы разработки эволюционировали черезвычано сильно, но что осталось неизменным — это человеческая природа.
И конфликт внутри команды по прежнему может повлиять на сроки и бюджет сильнее чем любые технические риски.
Я вас оченб прекрасно понял, не надо мне 3й раз намекать на ваш возраст и опыт — я тоже не мальчик и про технологии не написал тут ни слова.
Конфликты внутри команды — это банальные human factor риски, которые в инженерии вполне себе нормально митигируются уже десятки лет.
Кстате базовые инструменты митигирования этих рисков как то
— унификация всего чтоможно унифицировать
— максимально возможная независимость от «незаменимых» сотрудников
— разумное документирование
— ротация людей между командами
идут в разрез со многими из указанных в статье «советов».
Конфликты внутри команды — это банальные 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 человек в год.
Если вы делаете что-то уникальное не очень похожее на аналоги (или если этих аналогов просто нет), то вам нужна команда
Можно долго и нужно обсуждать ваш длинный и слабосвязанный пост, но давайте начнем с простого.
Вы и вправду думаете что автор статьи описывает решение каких-то уникальных, инновационных проблем программирования?
А что ещё вы можете делать в IT? Клепать копии того, что кто-то однажды уже сделал?
Ну так производитель оригинала снизит цену — и вы останетесь «на бобах». Себестоимость-то копии нулевая — сколько бы ни стоил оригинал!
Ну так производитель оригинала снизит цену — и вы останетесь «на бобах». Себестоимость-то копии нулевая — сколько бы ни стоил оригинал!
Думаю, тут очень кстати будет фраза из одного замечательного фильма: «Я хотя бы попробовал!». Человек высказал, в общем-то, дельные мысли, дискуссия таки завязалась :)
По моему мнению, любая существующая команда уже представляет некую ценность (патологии бывают, но не часто и определяются на старте). Правильно сориентировать каждого игрока, суметь нейтрализовать/погасить трения и научиться выигрывать этим составом — вот что работает, по моему опыту. И по факту это гораздо быстрее, чем «набрать новую команду» и эффективнее. Хотя эта работа не так наглядна, без особого драматизма и эффектных штук.
Новую команду набирать не обязательно. Вполне можно изменить старую. Был свидетелем. Но состав немного изменился.
В общем, поделюсь ситуацией, которая, откровенно говоря, патовая. Партнеры уходят, конкуренты обходят, а начальства ничего не может с этим поделать. И пойдем прям по пунктам.
1. Все дружно молчат. Что начальство, что остальные сотрудники. Когда я поднимаю тему составления плана выхода из сложившейся стагнации, никто должным образом не реагирует. Хотя уже бонусы не платят пол года и перспектив выхода никаких.
2. Работаем, как и положено, с 9 до 18, но при этом задач с гулькин нос. В основном, мелкая текучка. А там, кто чем занимается: народ смотрит фильмы, рисует, читает. Начальству вообще до лампочки.
3. Руководители появляются и уходят, как призраки. Ничего толкового не сообщают ни то, что отделу разработки, но и менеджерам.
4. Целеустремленность работников близка к 0. Стагнация уже больше года, и все становится только хуже. Народ думает, как свалить, но, естественно, все молчат.
5. Есть одно большое обещание от руководства, что скоро будет большой проект. И все будет хорошо. По этому проекту действительно ведутся переговоры. Но уже как пол года ни к чему не приводят.
Вот, что значит «эффективная команда».
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% дела сделано. Помните:
Люди, которые не являются программистами, смотрят на экран и видят какие-то пиксели. И если кажется, что эти пиксели могут собраться в программу, которая что-то делает, они думают «да ну, сколько там ещё осталось, чтобы она просто начала действительно работать?»Удивительным образом люди, способные это понять — не всегда бывшие программисты (хотя это помогает) и не всегда бывшие программисты способны это понять (вот это меня удивляет всегда больше всего).
А вот правильно, с цифрами, обьяснить бизнесу, почему им необходим тот или иной рефакторинг, вписать его в бизнес план, скоммуницировать с командой, что «мы все обязательно исправим, но поэтапно, первый шаг через 3 месяца, вот таска в жире» — это одна из задач менеджера. Хорошего менеджера :)
Это правда, конечно, но есть странный парадокс: чем более вменяем у вас «бизнес» и чем больше о его нуждах знает команда (и, наоборот, чем больше знает о нуждах команды бизнес), тем меньше потребность в менеджерах. В предельных случаях (когда бизнес не очень большой — скажем до 50-100 человек) можно обойтись и без него вообще.
В предельных случаях (когда бизнес не очень большой — скажем до 50-100 человек) можно обойтись и без него вообще.
А платить то кто будет? Это шедевр, распечатаю и повешу на стену. Сори, не удержался :)
Бухгалтерия, однако. Скорее всего — даже не входящая в штат компании.В предельных случаях (когда бизнес не очень большой — скажем до 50-100 человек) можно обойтись и без него вообще.А платить то кто будет?
Это шедевр, распечатаю и повешу на стену. Сори, не удержался :)Пожалуйста, мне не жалко.
Бухгалтерия, однако
Это еще один шедевр, очень кратко и однозначно идентифицирующий ваше понимание бизнеса.
В небольшом бизнесе на 50-100 человек внезапно появляется какая то отдельная от бизнеса бухгалтерия, готовая платить «за все» — это прекрасно, продолжайте в том же стиле :)
В небольшом бизнесе на 50-100 человек внезапно появляется какая то отдельная от бизнеса бухгалтерия, готовая платить «за все» — это прекрасно, продолжайте в том же стиле :)Знаете вас вопрос и мой ответ — это классическое: «а откуда деньги» — «из тумбочки».
Понятно, что даже если бизнес небольшой, то у него есть какие-то договора с кем-то и кто-то ему перечисляет какие-то деньги. Но когда у вас есть полдюжины или даже две дюжины работников, то никого, кроме владельца бизнеса, для решения вопроса «кому сколько заплатить» не нужно, а количество транзакций не окупает наличие отдельного бухгалтера на полную ставку. А менеджер себя окупает — но только если команду создать не удалось и люди вместе работают… плохо.
Зачем тут ещё какой-то менеджер и в чём будут состоять его обязанности — мне решительно непонятно.
И да — это не теоретические изыски, это то, как были устроены большинство компаний в которых я работал (да-да их была не одна и не две).
Забавный текст. В части «как не» — описана конкретика, примеры фейлов, которые можно примерить на себя, можно обобщить.
В части «brave new world» — лозунги («Наши действия подчинены общей цели» и т.п.)
Ощущение, что мне в очередной раз пытаются что-то продать.
В части «brave new world» — лозунги («Наши действия подчинены общей цели» и т.п.)
Ощущение, что мне в очередной раз пытаются что-то продать.
Impact mapping. Gojko Adzic (не представляю как по-русски написатьГойко Аджич он:)
Инфантилизм 80лвл. Некоторые из тезисов важны, некоторые — нет, сама подборка — детский сад.
Сходите в Tata Consulting и расскажите им что не надо решать за сотрудников как им работать, поинтересовавшись предварительно ее макропоказателями.
Сходите в Tata Consulting и расскажите им что не надо решать за сотрудников как им работать, поинтересовавшись предварительно ее макропоказателями.
Мне кажется выводы в статье как-то с потолка. "Идеал — вот так, плохо — вот так". Что с этим делать и какие могли быть причины? Почему это — хорошо, а вот это плохо?
Команда — это динамическое образование. У неё есть стадии развития, зависимость от корпоративной культуры, от цели. Для каждой корпоративной культуры и стадии развития понятие "идеальной" команды — разное. Описание идеала в статье прекрасно может подходит для "бирюзовых" компаний в которых большая часть сотрудников уже давно работает, но для какой-нибудь жесткой конкуретной компании "up or out" с хорошей текучкой это неприменимо вообще и с таким "идеалом" задачи IT подразделение выполнять не сможет.
В целом это всё хорошо расписано в книгах по регулярному менеджменту и командообразованию, а в статье зафиксирована только односторонняя позиция которая подается как общий идеал. Стоит добавить всё-таки в каких компаниях вы работали и в каких условиях для команды можно ориентироваться на эти положения.
Класс! Статья, как ориентир, как описание (недостижимого?) идеала, к которому нужно стремиться. Хотя бы не забывать смотреть в эту сторону. И пусть идеализм.
Так, сударь, похвастайтесь предметно. Расскажите о той идеальной команде, в которой вы работали и, что более интересно, расскажите о той почти идеальной команде, которую вы создали, назовите названия компаний.
Неловко будет, если выяснится, что все, что вы накропали — это фантазии на опыте мелкого аутсорсера из Томска, правда?
Неловко будет, если выяснится, что все, что вы накропали — это фантазии на опыте мелкого аутсорсера из Томска, правда?
«Накропал» в личку.
Я не стесняюсь показывать своё лицо, рассказывая свои мысли. А вы?
Я не стесняюсь показывать своё лицо, рассказывая свои мысли. А вы?
А я аноним, да, вы правильно подметили.
Владимир, на самом деле суть не в конкретных названиях компаний, а в том, что ваш опыт очень специфичен.
Давайте честно, если бы вы назвали козлом, например, (светлой памяти) Сегаловича, то было бы всем понятно, что козел именно вы. Вам кажется, что git flow спускают для того, чтобы отчитаться. Окей, это потому что вы не работали в серьезной разработке. Если вам кажется, что «правила разработки» — это заговор злых корпоративных зомби — посмотрите на документацию разработки ядра линукса, например. Она строже, чем во многих компаниях.
Владимир, на самом деле суть не в конкретных названиях компаний, а в том, что ваш опыт очень специфичен.
Давайте честно, если бы вы назвали козлом, например, (светлой памяти) Сегаловича, то было бы всем понятно, что козел именно вы. Вам кажется, что git flow спускают для того, чтобы отчитаться. Окей, это потому что вы не работали в серьезной разработке. Если вам кажется, что «правила разработки» — это заговор злых корпоративных зомби — посмотрите на документацию разработки ядра линукса, например. Она строже, чем во многих компаниях.
Давайте я попробую прояснить свою позицию.
Суть не в том, чтобы назвать кого-то козлом, а в том чтобы сказать о проблеме, которая тебя беспокоит.
Нет, мне так не кажется. Я уже ответил на подобный комментарий habrahabr.ru/post/337048/#comment_10396832
У меня складывается ощущение, что вы придираетесь к примерам, на которых я объяснял свою позицию, а не к самой позиции. Зачем? Примеры это просто красочные вымышленные ситуации.
И опять мне так не кажется. А кажется мне, что команда сама сформирует правила работы и будет их яростно отстаивать.
если бы вы назвали козлом
Суть не в том, чтобы назвать кого-то козлом, а в том чтобы сказать о проблеме, которая тебя беспокоит.
Вам кажется, что git flow спускают для того, чтобы отчитаться
Нет, мне так не кажется. Я уже ответил на подобный комментарий habrahabr.ru/post/337048/#comment_10396832
У меня складывается ощущение, что вы придираетесь к примерам, на которых я объяснял свою позицию, а не к самой позиции. Зачем? Примеры это просто красочные вымышленные ситуации.
«правила разработки» — это заговор злых корпоративных зомби
И опять мне так не кажется. А кажется мне, что команда сама сформирует правила работы и будет их яростно отстаивать.
сказать о проблеме, которая тебя беспокоит.
Тут ничего выдумывать не надо, надо следовать установленному процессу. Если у тебя кондиционер барахлит — звони по телефону 007 в хозслужбу. Если с жирой неполадки — пиши админам. Если есть что сказать по процессу разработки — назначай встречу со своим линейным менеджером. А вот директора козлом называть — неразумно и проблему не решает. Кстати, как вы думаете, откуда эти хорошие процессы берутся? Может быть их команда выдумывает?
Нет, мне так не кажется. Я уже ответил на подобный комментарий
Из-за вашей специфики у вас какой-то странный страх перед неким «насильственным внедрением». На самом деле внедрить процессы никого не насилуя — задача типичная для менеджера и хорошо описанная (хотя может быть в реальной жизни и не тривиальная).
Подумав еще…
Да, мой опыт действительно специфичен. В дальнейшем постараюсь обращать больше внимания описанию контекста.
Да, мой опыт действительно специфичен. В дальнейшем постараюсь обращать больше внимания описанию контекста.
Полагаю, мысли будут полезны не только в рабочих отношениях. Город особого значения не имеет.
Кому интересна техника Impact Mapping могу порекоммендовать онлайн инструмент для построения IM, который позволяет создавать, шарить и экспортировать карты в pdf и png. uxpressia.com/impact-map-online-tool
Был уверен, что это перевод, очень «английское» построение предложений и вообще манера излагать.
Если вы решаете за сотрудников как им работать — вы не команда. Вы спускаете сверху git flow, список статусов задач, рабочие часы с 9:00 до 18:00?
Мой небольшой опыт показывает, что если кто-нибудь (необязательно РМ или начальство, просто кто-то, кому не все равно) не придумает, как организовывать работу (банально, конвенции по именованию файлов/директорий, конвенции по кодированию, rebase или merge и т.д.), то все будут делать это как попало. Если всех не приучить юзать git, то у кого-то вообще никакого версирования не будет, кто-то будет архивчики руками делать ежедневно, кто-то svn себе поставит. И код будет расползаться просто файлами по скайпу.
Возможно, если у вас уже есть настоящая команда, в которой все сознательные и рациональные люди, то они видят эту проблему и решают ее сообща, но в реальности таки придется некоторые вещи педалировать сверху, иначе будет просто помойка.
Да! Педалировать придется пока не завершится переходный процесс и группа разработчиков не станет командой.
Но педалировать надо не git, часы работы и конвенции, а правила командной работы. Иначе погрязнете в микроменеджменте.
Как правильно заметил коллега с «небольшим» опытом, пока вы не определите основные правила, конвенции, workflow… вы не получите общего движения всей команды в одном направлении. Если у вас будет 3,5,7 команд работающих в одном проекте ваша теория приведет к появлению «лебедь, рак и щуки», и вам придется навязать каждой конкретной команде правила, которые возможно одобрит не каждая команда. Это придется сделать, и как не странно именно для того что бы предоставить больше свободы в действиях, при чем в рамках существующих ограничений. Ведь «основная задача руководителя — создавать условия труда, а не раздавать команды.»
3, 5, 7 команд работающих в одном проекте — да, возможно, в этом случае не сработает. Но вы ведь не пробовали, верно? Справедливости ради скажу, что я тоже не пробовал в таких условиях.
Я не руководитель, опыт у меня и правда небольшой (да еще в одной компании), я просто вижу проблемы вокруг себя. У нас даже просто сидящие в разных концах комнаты люди умудрялись развивать маленькие фабрики велосипедов, несовместимые друг с другом. Просто потому, что они не общались. Каждый сидит в своем углу и делает свое маленькое дело. Что происходит, когда люди сидят в разных комнатах — я вообще молчу.
Отмечу, что у нас своя специфика, очень много небольших проектов, поэтому разработчикам существенно проще не контактировать друг с другом. Но тем не менее.
Отмечу, что у нас своя специфика, очень много небольших проектов, поэтому разработчикам существенно проще не контактировать друг с другом. Но тем не менее.
У нас даже просто сидящие в разных концах комнаты люди умудрялись развивать маленькие фабрики велосипедов, несовместимые друг с другом.
Ну да. Отсутствие или неполнота коммуникации и общепринятых стандартов в команде — рассадник решений «на коленке», причём повторенных у разных людей по-разному, грубо говоря, об одном и том же. Вы как-то с этим боретесь? Или это уже устоявшаяся практика?
Пытаемся. Наиболее инициативные товарищи образовали т.н. «Совет Эльфов», который принимал все судьбоносные решения подобного рода. Но всегда есть несколько человек, с которыми ничего не поделать. Или встают в позу, или отмахиваются, или просто не видят проблемы. Вот тут бы, на мой взгляд, как раз и стоило бы слегка надавить «административным ресурсом», которым совет не обладает :)
Статья добротная. Но вот еще бы понять, как бороться с синдромом Not Invented Here и с тем, что «нам некогда заниматься изучением чего-то там, нам надо писать код», сиюминутным исполнением задач без вдумчивого анализа и хватанием за голову впоследствии...
Если вы не знаете целей и интересов ваших сотрудников — вы не команда
От работодателя требуется лишь исправно платить зарплату. Еще не хватало, чтобы он в личную жизнь лез.
Это прекрасно, когда у тебя в багаже есть опыт работы в здоровых системных компаниях. И особенно помнятся, конечно, их колелктивы! Мнение автора имеет место быть.
НЛО прилетело и опубликовало эту надпись здесь
1-ый пункт между прочим самый важный. Таки почитайте.
По второму пункту еще раз напишу, что нет противоречия между «выгодно для бизнеса» и «команда решает как работать». Точнее конфликт может быть, но лидеру нужно его разрешить. Иначе Команды не получится.
По второму пункту еще раз напишу, что нет противоречия между «выгодно для бизнеса» и «команда решает как работать». Точнее конфликт может быть, но лидеру нужно его разрешить. Иначе Команды не получится.
Вот под всем этим читается, что команда должна разделять интересы бизнеса и собственника. А у него один вполне конкретный интерес — извлечение прибыли, ибо он капиталист. И да, можно сделать классный проект, над которым будет интересно работать, но в какой-то момент встанет вопрос монетизации, тогда уже «интересность» теряется в ущерб извлечению прибыли. И задачи ставятся, не добавить новую фичу, а сделать так, чтобы пользователь заплатил.
Интересы бизнеса говорят — сдать проект к такому-то числу с такими-то фичами, ибо конференция, контракт или что-то еще. А интересы команды говорят — надо перейти на другой фреймворк, все отрефакторить, все обвешать тестами и т.п. И угадайте кто чьими интересами должен проникнуться.
Да, существуют несколько корпораций в которых возможна такая командная работа и «свободная охота». Но для остальных это чистая страна эльфов, работать так как хочешь и над чем хочешь. Потому что бизнес и извлечение прибыли. Ну это если зарплата нужна, конечно. А в стартапе очень даже можно такую команду собрать, если инвестор богатый и добрый. Или если нет семьи с ипотекой…
Интересы бизнеса говорят — сдать проект к такому-то числу с такими-то фичами, ибо конференция, контракт или что-то еще. А интересы команды говорят — надо перейти на другой фреймворк, все отрефакторить, все обвешать тестами и т.п. И угадайте кто чьими интересами должен проникнуться.
Да, существуют несколько корпораций в которых возможна такая командная работа и «свободная охота». Но для остальных это чистая страна эльфов, работать так как хочешь и над чем хочешь. Потому что бизнес и извлечение прибыли. Ну это если зарплата нужна, конечно. А в стартапе очень даже можно такую команду собрать, если инвестор богатый и добрый. Или если нет семьи с ипотекой…
И опять повторю — нет противоречия между выгодой бизнеса и командностью.
Это предположение.
Я вот другого мнения — все мы сидим на игле общественного одобрения. Все хотят быть полезными. Поэтому разработчик хочет сделать так чтобы бизнес им был доволен.
интересы команды говорят — надо перейти на другой фреймворк
Это предположение.
Я вот другого мнения — все мы сидим на игле общественного одобрения. Все хотят быть полезными. Поэтому разработчик хочет сделать так чтобы бизнес им был доволен.
Интересы бизнеса говорят — сдать проект к такому-то числу с такими-то фичами, ибо конференция, контракт или что-то еще.Сиюминутные интересы. Исправление багов — денег стоит и разница между исправлением проблем на этапе дизайна и на этапе после внедрения — три порядка. Если у вас есть основания полагать что за 2-3 года (между разработкой и внедрением) ваша компания вырастет в тысячу раз — это может быть оправдано, иначе создание технического долга — иллюзия.
А интересы команды говорят — надо перейти на другой фреймворк, все отрефакторить, все обвешать тестами и т.п.Это те же самые интересы безнеса — только в будущем.
И угадайте кто чьими интересами должен проникнуться.А не нужно ничем «проникаться», нужно посчитать. Слева — сколько займёт внедрение нового фреймворка, справа — ожидаемый выигрыш. Не можете такого написать? Даже прикидок нет? А тогда с чего вы решили, что переход на новый фреймворк вообще имеет смысл?
Стратегией хорошо мыслить, когда есть финансовая подушка. А когда сколько потопал, столько и полопал, тут уже рубить сплеча не приходится. Если нужно к новому раунду финансирования сделать вот эту фичу с костылями и говнокодом, то придется делать. Это альтернатива переезду на новый фреймворк, который когда-то даст выигрыш, но сейчас оставит без зарплаты всю команду. И хорошо, если команда это понимает.
Я бы сказал так, что хорошо, если команда понимает, что деньги сыпятся не с неба, а являются производной их труда. Вот тогда у них может появиться соответствующая мотивация. Казалось бы, очевидный тезис, но не все его принимают. Так как в идеале хочется делать интересные вещи и получать за это деньги. Тут понятно, что мотивация высокая и командная работа на высоте. А вот когда надо за деньги делать неинтересные вещи, тут мотивация падает. И часто это «перешагивание через голову» всей команды.
Я бы сказал так, что хорошо, если команда понимает, что деньги сыпятся не с неба, а являются производной их труда. Вот тогда у них может появиться соответствующая мотивация. Казалось бы, очевидный тезис, но не все его принимают. Так как в идеале хочется делать интересные вещи и получать за это деньги. Тут понятно, что мотивация высокая и командная работа на высоте. А вот когда надо за деньги делать неинтересные вещи, тут мотивация падает. И часто это «перешагивание через голову» всей команды.
В большинстве тезисов согласен с автором. Как раз сейчас занимаюсь построением команды в отделе техподдержки. С некоторыми персонажами пришлось расстаться, которые приходили поиграть, посидеть в соцсетях за деньги работодателя. Очень многое приходится менять, от процессов до мышления. Делаю ежемесячные совещания отдела, хотя это не просто с нашей спецификой, на которых все рассказывают о своих выполненных задачах, планах, высказывают предложения, которые обсуждаются всеми.
По поводу предложений: я могу принять решение по какому-либо вопросу, но интереснее и лучше когда это проходит обсуждение в коллективе, потому что могут быть высказаны улучшения или наоборот блокирующие факторы, которые одному человеку сложно сразу увидеть и осознать.
По поводу предложений: я могу принять решение по какому-либо вопросу, но интереснее и лучше когда это проходит обсуждение в коллективе, потому что могут быть высказаны улучшения или наоборот блокирующие факторы, которые одному человеку сложно сразу увидеть и осознать.
Делаю ежемесячные совещания отдела, хотя это не просто с нашей спецификой, на которых все рассказывают о своих выполненных задачах, планах, высказывают предложения, которые обсуждаются всеми.
Не надо так делать. Ничего хорошего в таких совещаниях нет и неизвестно. За всю свою жизнь ни разу не встречал коллективов, где бы подобные совещания чему-то способствовали. Либо таковые встречи заканчивались плачевно для коллектива/проекта/компании, либо прекращали быть (тоже плачевно для коллектива, потому что приводили к смене руководителя, а новый руководитель — он и есть новый руководитель).
Планы отдела огласить и обсудить полезно. Ретроспективу провести тоже полезно. Но, пожалуй, рассказывать о планах и задачах каждого — громоздковато будет.
План+ретроспектива — соглашусь;
обсудить — только при необходимости, каковая имеет место быть далеко не всегда.
А вот обсуждение планов и задач каждого — оно не только громоздко, оно нередко выливается в какое-нибудь громогласное непотребство, которое приходится пресекать руководителю.
Соответственно, такой сбор — оно уже совсем не совещание, а какая-нибудь планёрка минут на 5-15.
Разбираться с «непотребством», как вы высказались, и есть одна из задач руководителя, надо понимать почему оно возникает, если у человека есть боль и он ей делится, то ее надо решить, скорее всего это не только у него наболело. А если человек себя намеренно так ведет, то наверное ему не место в коллективе. Это как раз позволяет прокачивать коммуникационные и прочие навыки, поэтому вижу в этом скорее плюс, чем минус.
Разбираться с «непотребством», как вы высказались, и есть одна из задач руководителя
Спасибо за понимание. А то тут много чего понаписали про то, что руководитель не нужен. Либо о том, что команда вполне себе может решать задачи, которые обязан решать руководитель.
Про боль. По личному моему опыту начинать решение проблем всё-таки предпочтительнее с приватной беседы. Боль — она вполне себе может быть обусловлена личными причинами, озвучивать которые публично вполне себе может быть не совсем приемлемо.
И самое главное — когда появляется боль, требующая внимания руководителя, эту боль надо решать немедленно, а не на плановом совещании.
И второе. Я как-то вот так предпочитаю направлять свои усилия, чтобы исключить вероятность нештатных ситуаций, а не решать проблемы. Соответственно, комфортно себя чувствую только там, где руководители понимают, что предотвратить проблему существенно дешевле, нежели постоянно решать возникающие проблемы.
У нас в коллективе ежедневные планёрки — и ничего страшного. Как по мне, это наоборот помогает, когда проговариваешь, что делал вчера, что собираешься делать сегодня. Даже если планы в итоге нарушаются. По крайней мере, все более менее в курсе, что происходит с проектами.
Не готов согласиться, потому что я делаю это в свободной манере и коллегам, это нравиться, они высказывают предложения, про Чебурашек (так мы называем проблемы) и т.п., укладываемся в час. В другой компании это делалось еженедельно, сотрудник должен был составить отчет в электронном виде, переносов не делалось и в довершение, руководитель отдела позволял себе на меня кричать, из-за того что у меня не все на месте, так как они ушли к пользователям. Итого, каждая компания, коллектив, подразделение выбирают свою частоту собраний, основываясь на специфике работы, где-то это совсем невозможно или не нужно.
Как в техподдержке без распоряжений и приказов? Автор «Мы» наделяет безоговорочно персональными свойствами, с единой волей и сознанием. Во-первых, такого не бывает. Коллективная ответственность в оперативных вопросах — неэффективна (в команде исследователей с неограниченным бюжетом — может быть и реализуема с пользой для дела). Во вторых, обратная сторона этого — уничтожение индивидуальности в команде, что сразу же вносит в команду источник-потенциал её разрушения. По мне, надо культивировать в команде правильное осмысление таких тем как субординация, на современном уровне — руководитель — он не лучше тебя и не главнее, это тот, человек который при наличии вариантов — принимает решение, а не сразу же собирает планерки (но планерки вполне могут быть в вариантах решений и вполне могут руководителем конечно иногда выбираться, на основании каких либо причин… например, методологических или регламентационных )
Текст — клише с позитивной коннотацией.
А я вот чего не пойму, тут есть пункт:
т.е., если не получилось (не хватило опыта/знаний) завлечь человека своей целью, то он просто выкидывается. И до каких пор так? Пока не находится человек достаточно лояльный/«пластилиновый»/неуверенный или признаётся, что ты не руководитель и надо уходить самому?
Ведь очень удобный пункт, так можно увольнять всех подряд, не замечая, что проблема в руководителе…
Общая цель формулируется так, что учитывает цели каждого. Более или менее. Если есть человек, цель которого мешает достижению общей цели — он покидает команду.
т.е., если не получилось (не хватило опыта/знаний) завлечь человека своей целью, то он просто выкидывается. И до каких пор так? Пока не находится человек достаточно лояльный/«пластилиновый»/неуверенный или признаётся, что ты не руководитель и надо уходить самому?
Ведь очень удобный пункт, так можно увольнять всех подряд, не замечая, что проблема в руководителе…
У меня вопрос. Что важно для сотрудников чтобы они себя чувствовали как команда и работали над достижением общей цели. Ведь действительно многие уходят без объяснения реальных причин.
Вот такое у меня мнение по этому вопросу habr.com/post/349668
Моё мнение, основанное на моём же опыте — все люди разные. Какие-то базовые правила есть, которые все сводятся просто к человеческому отношению в коллективе. Когда коллег уважают, мнения выслушивают, начальники не самодурствуют, а зарплата выплачивается вовремя, и в приятном объеме. Но универсальной стратегии управления, которая сделает всех довольными, в природе не существует. Ценности, ожидания, психотипы у каждого свои. Поэтому все равно кто-то не будет приживаться в команде, кто-то «попользуется компанией» и уйдёт и т.д. Ничего страшного в этом нет, это абсолютно естественный процесс.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Сударь, ваша команда — не команда