Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 63
Спасибо, Кэп!
![[Спасибо, Капитан Очевидность]](https://habrastorage.org/getpro/megamozg/comment_images/545/9f9/f54/5459f9f544c40122753651bcdb8d2713.png)
Не то что бы я толераст, но слово «ниггеры» режет слух.
Слава богу, что мы не в Америке. Пока еще можно говорить, что думаешь.
Я вот, чтобы жить как белый человек, вкалываю как негр. Где-то меня нае… ли!
Я вот, чтобы жить как белый человек, вкалываю как негр. Где-то меня нае… ли!
ИМХО следует различать русское слово «негр» происходящее от испанского «negro» («чёрный (цвет)») и американское «nigger», которое использовалось для пренебрежительного наименования негров.
Употребление слова «ниггер» не имеет никакого отношения к свободе. В любом языке есть оскорбительные названия тех или иных наций и рас. Я сомневаюсь, что Вы обращаетесь к своим коллегам еврейского происхождения, используя слово «жид». Т.к. это слово в русском языке является оскорбительным, также как и «ниггер» в английском.
Просто у нас в стране из-за неадекватного перевода американский фильмов население не понимает, что в большинстве боевиков ему показывают не нормальных людей, а уголовников, низы общества, урок, гопников и откровенное быдло. Перенимать их язык и манеру общения всё равно, что «ботать по фене».
Просто у нас в стране из-за неадекватного перевода американский фильмов население не понимает, что в большинстве боевиков ему показывают не нормальных людей, а уголовников, низы общества, урок, гопников и откровенное быдло. Перенимать их язык и манеру общения всё равно, что «ботать по фене».
За смайлики-скобочки надо убивать )))))))))))))
В-четвертых, везде, где применяются такие методологии — они применяются адаптивно. То есть не команды подстраиваются под «ритуалы», а «ритуалы» подстраиваются под команды.
Самое распространенная ошибка тимлидов, внедряющих какой-либо процесс.
Все методики написаны кровью сотен тимлидов, прожекменеджеров и кодеров, они прошли все этапы становления и оптимизации.
Это касается многих методологий, не только разработческих.
методологии нужно внедрять, а не адаптировать под свой процесс
Scrum-мастер? :))
Нет двух одинаковых команд. На процесс влияет все — и опыт разработки, и инициативность членов команды (между прочим, это очень важный момент в Скраме), и наличие дедлайнов, и количество непредвиденных задач, которые нужно выполнять срочно (Expedite-задачи в Канбане). Просто куча всего.
На одной из наших команд, к примеру, тупо внедрили классический скрам. Через десять спринтов оказалось, что velocity в среднем равняется 0.2, при этом в каждом спринте скачет то до 0.8, то до меньше 0.1. В итоге, проанализировав ситуацию, выяснили, что Скрам, по многим причинам, в чистом виде работать в этой команде просто не может. И планирование спринта, которое каждый раз занимало целый день, было, по большей части, потерей времени, ведь все детальные эстимейты, на которые тратились часы planning poker'а, в итоге все равно оказывались нереальными и их никак нельзя было применять для оценок и планирования.
В итоге разработали нечто вроде гибрида между Канбаном и Скрамом, что и работает вполне успешно до сих пор.
Никогда нельзя тупо внедрять методологии, если конечно у вас не сферическая команда с давлением ровно в одну атмосферу.
На одной из наших команд, к примеру, тупо внедрили классический скрам. Через десять спринтов оказалось, что velocity в среднем равняется 0.2, при этом в каждом спринте скачет то до 0.8, то до меньше 0.1. В итоге, проанализировав ситуацию, выяснили, что Скрам, по многим причинам, в чистом виде работать в этой команде просто не может. И планирование спринта, которое каждый раз занимало целый день, было, по большей части, потерей времени, ведь все детальные эстимейты, на которые тратились часы planning poker'а, в итоге все равно оказывались нереальными и их никак нельзя было применять для оценок и планирования.
В итоге разработали нечто вроде гибрида между Канбаном и Скрамом, что и работает вполне успешно до сих пор.
Никогда нельзя тупо внедрять методологии, если конечно у вас не сферическая команда с давлением ровно в одну атмосферу.
Где-то я это уже видел…
История реально клевая и уже много где используется в качестве обоснования своей точки зрения.
Какой точки зрения? Что прежде чем что-то делать, нужно подумать? И что нужно понимать, зачем ты это делаешь и что происходит «под капотом»? Хорошая точка зрения, поддерживаю.
Вот только казалось бы, при чём тут Scrum? То же самое применимо и к вождению автомобиля, и к использованию компьютера, и к разведению аквариумных рыбок.
Вот только казалось бы, при чём тут Scrum? То же самое применимо и к вождению автомобиля, и к использованию компьютера, и к разведению аквариумных рыбок.
Однажды, таки им(туземцам) перепал «ништяк». Они потом еще христианство троллили, мол наш б-г послал нам, а ваш за 2 тысячи лет???
Если в вашей команде есть человек, который предлагает использовать BuzzWord, то возможны два варианта:
1. Это менеджер у которого слишком много свободного времени и следовательно он должен быть исключен из команды.
2. У вас действительно есть проблемы в коммуникации, значит нужно решать их, а не интегрировать целую систему.
1. Это менеджер у которого слишком много свободного времени и следовательно он должен быть исключен из команды.
2. У вас действительно есть проблемы в коммуникации, значит нужно решать их, а не интегрировать целую систему.
В-четвертых, везде, где применяются такие методологии — они применяются адаптивно. То есть не команды подстраиваются под «ритуалы», а «ритуалы» подстраиваются под команды.
К сожалению, не везде.
И вот там где это не происходит, особо выигрыша методики не приносят.
На таких людей как раз и направлен троллинг карго-культом.
Ништяков перепало ;)
Военные скинули неубиваемый ноут, солнечные батареи, и спутниковый модем. Шаман с помощью богов всё соединил и вышел в Интернет. А там дело техники: ebay.com, оплатить, указать адрес доставки. Деньги там же в инете можно заработать. И всё, деревня одета.
А если доставлять будут также, ящиком из самолёта, то всё что остаётся шаману, это поддерживать эти ритуалы с палкам, нагружать работой людей (постройки деревянных самолётов, аеропортов и т.п.) чтобы меньше думали. Он даже сможет подгадывать день «дара с небес», отслеживая tracking number. Так его авторитет точно будет неубиваем. А сам может чатиться в инете с девчёнками.
>Попробовали, проанализировали результат. Стало лучше? Да — продолжаем экспериментировать и менять процессы дальше. Стало хуже — смотрим почему, ищем как улучшить.
Недавно вычитал в умной книге, «Пятая дисциплина» Искусство и практика самообучающейся организации, Сенге Питер (он Apple в 90х консультировал, что как бы круто для консультантов), что с точки зрения системного подхода, внедрение серьёзных изменений всегда влечет ухудшение в краткосрочной перспективе. Так что этот совет не всегда можно применять.
Троллить аджайлистов модно «Хоторнский экспериментом». В США в 30х проводился. Там работникам сказали, что ставят на них эксперимент с целью увеличения производительности труда. И результаты были очень удивительные. Что бы они не внедряли производительность труда всегда увеличивалась! Увеличили время на перекуры – производительность увеличилась, уменьшили – тоже увеличилась.
Agile – это философия (с манифестом, лять) которая включает в себя методологии Scrum, XP, Kanban и др. Писать «Scrum/XP/Agile» не совсем корректно, лучше писать или просто методологии Agile или Scrum/XP/Kanban/
P.S. я сертифицированный скрам мастер, простите меня :)
Недавно вычитал в умной книге, «Пятая дисциплина» Искусство и практика самообучающейся организации, Сенге Питер (он Apple в 90х консультировал, что как бы круто для консультантов), что с точки зрения системного подхода, внедрение серьёзных изменений всегда влечет ухудшение в краткосрочной перспективе. Так что этот совет не всегда можно применять.
Троллить аджайлистов модно «Хоторнский экспериментом». В США в 30х проводился. Там работникам сказали, что ставят на них эксперимент с целью увеличения производительности труда. И результаты были очень удивительные. Что бы они не внедряли производительность труда всегда увеличивалась! Увеличили время на перекуры – производительность увеличилась, уменьшили – тоже увеличилась.
Agile – это философия (с манифестом, лять) которая включает в себя методологии Scrum, XP, Kanban и др. Писать «Scrum/XP/Agile» не совсем корректно, лучше писать или просто методологии Agile или Scrum/XP/Kanban/
P.S. я сертифицированный скрам мастер, простите меня :)
— А давайте попробуем scrum?
— Давайте!
— А давайте программировать оперционные системы на перфокартах?
— Давайте!
Менять технологии разработки «просто так» — это идиотизм. Может быть в каком нибудь стартапе из пяти студентов это веселая развлекуха, что бы было не скучно, то в любой более менее значительной компании смена методологии это адский батхерт для всех. И чем крупнее компания и опытнее разработчики — тем хуже. Постоянное перестраивание бизнес процессов просто ради эксперимента это на самом деле непрерывный бардак в течении всего этого времени и не более того.
Любая методология, как и любой инструмент, предназначена для строго определенных целей. Казалось бы очевидно?
Тролить любителей конкретной методологии не только можно, но и нужно. Для каждого конкретного коллектива, и даже более того, для каждого конкретного проекта, а иногда и даже отдельной стадии этого проекта должна быть подобрана своя методология(или комбинация методологий), которая наиболее полно отвечает его потребностям. Человек который говорит «Я исповедую ...» в действительности говорит нам «не подпускайте меня к управлению, я сделаю все так как мне хочется, а не так, как это в действительности нужно». Также как и все люди, которые исповедуют какие то отдельные технологии или методологии.
Я честно говоря вообще не понимаю, зачем эти все скрамы нужны. По мне, если руководитель внедряет скрам или иже с ними — значит он халтурит. Вместо того что бы, как хороший руководитель, подобрать режим работы наиболее подходящий его команде, он халтурит, внедряя шаблонное решение.
И да, в ИТ действительно гораздо больше умных людей, и меньше идиотов, но это вовсе не означает что их мало. Более того, чем дальше, тем их больше — ИТ постепенно идет в народ, и как следствие народ идет в ИТ, как следствие количество идиотов в ИТ медленно, но верно приближается к среднестатистическу значению по планете.
— Давайте!
— А давайте программировать оперционные системы на перфокартах?
— Давайте!
Менять технологии разработки «просто так» — это идиотизм. Может быть в каком нибудь стартапе из пяти студентов это веселая развлекуха, что бы было не скучно, то в любой более менее значительной компании смена методологии это адский батхерт для всех. И чем крупнее компания и опытнее разработчики — тем хуже. Постоянное перестраивание бизнес процессов просто ради эксперимента это на самом деле непрерывный бардак в течении всего этого времени и не более того.
Любая методология, как и любой инструмент, предназначена для строго определенных целей. Казалось бы очевидно?
Тролить любителей конкретной методологии не только можно, но и нужно. Для каждого конкретного коллектива, и даже более того, для каждого конкретного проекта, а иногда и даже отдельной стадии этого проекта должна быть подобрана своя методология(или комбинация методологий), которая наиболее полно отвечает его потребностям. Человек который говорит «Я исповедую ...» в действительности говорит нам «не подпускайте меня к управлению, я сделаю все так как мне хочется, а не так, как это в действительности нужно». Также как и все люди, которые исповедуют какие то отдельные технологии или методологии.
Я честно говоря вообще не понимаю, зачем эти все скрамы нужны. По мне, если руководитель внедряет скрам или иже с ними — значит он халтурит. Вместо того что бы, как хороший руководитель, подобрать режим работы наиболее подходящий его команде, он халтурит, внедряя шаблонное решение.
И да, в ИТ действительно гораздо больше умных людей, и меньше идиотов, но это вовсе не означает что их мало. Более того, чем дальше, тем их больше — ИТ постепенно идет в народ, и как следствие народ идет в ИТ, как следствие количество идиотов в ИТ медленно, но верно приближается к среднестатистическу значению по планете.
Разрешите я вам в двух словах попробую рассказать, зачем по моему мнению, эти все скрамы нужны (У меня есть немного наивное желание улучшить ваше представление о методологиях).
Nota bene: Методология (от греч. учение о способах) система базисных принципов, методов и методик. Качество (успешность, эффективность) метода проверяется практикой, решением научно-практических задач — то есть поиском принципов достижения цели, реализуемых в комплексе реальных дел и обстоятельств.
До сих пор никто не знает как правильно разработать ПО, большинство проектов проваливается, выходят за рамки бюджета и т.д. и это создаёт темы для множества спекуляций на этот счёт. Но все пытаются скопировать способы и методики которыми пользуются успешные проекты. Так 10 лет назад, на горнолыжном курорте собрались успешные проектные менеджеры, и попытались найти у себя что то общее. Сошлись только на 4 ценностях, и 12 принципах. Так появился Agile Manifesto.
По моему мнению, Аджайл может быть полезен в двух случаях:
1. В молодых проектах, когда процесс приобретает некоторую зрелость, людей становиться больше, все устают от анархии и хотят хоть какой минимальной систематизации. Scrum может быть полезен как готовый шаблон который можно легко внедрить (легко только на первый взгляд). Например, вам нужно сыграть свадьбу, и вы беспокоитесь что ни будь пропустить (купить букетик невесты). С готовым шаблонам например можно узнать, что вы забываете делать регулярные ретроспективы (разбор полётов) и т.д.
2. В крупных корпорациях, когда успешно внедрили CMMI level 5, ISO, ГОСТ и т.д., но на поддержку самих процессов уходит больше затрат, чем пользы от них. Бюрократическая копания при естественном процессе может создаёт лишь еще больше правил, чем убрать их. Нужно переместить компанию из этапа Аристократизма в период Рассвета (терминология Адизиса). Для этого часто используют гибкие методологии. Но процедура внедрения в них проходит, гораздо сложней и требует куда больших затрат в чем молодых компаниях.
Nota bene: Методология (от греч. учение о способах) система базисных принципов, методов и методик. Качество (успешность, эффективность) метода проверяется практикой, решением научно-практических задач — то есть поиском принципов достижения цели, реализуемых в комплексе реальных дел и обстоятельств.
До сих пор никто не знает как правильно разработать ПО, большинство проектов проваливается, выходят за рамки бюджета и т.д. и это создаёт темы для множества спекуляций на этот счёт. Но все пытаются скопировать способы и методики которыми пользуются успешные проекты. Так 10 лет назад, на горнолыжном курорте собрались успешные проектные менеджеры, и попытались найти у себя что то общее. Сошлись только на 4 ценностях, и 12 принципах. Так появился Agile Manifesto.
По моему мнению, Аджайл может быть полезен в двух случаях:
1. В молодых проектах, когда процесс приобретает некоторую зрелость, людей становиться больше, все устают от анархии и хотят хоть какой минимальной систематизации. Scrum может быть полезен как готовый шаблон который можно легко внедрить (легко только на первый взгляд). Например, вам нужно сыграть свадьбу, и вы беспокоитесь что ни будь пропустить (купить букетик невесты). С готовым шаблонам например можно узнать, что вы забываете делать регулярные ретроспективы (разбор полётов) и т.д.
2. В крупных корпорациях, когда успешно внедрили CMMI level 5, ISO, ГОСТ и т.д., но на поддержку самих процессов уходит больше затрат, чем пользы от них. Бюрократическая копания при естественном процессе может создаёт лишь еще больше правил, чем убрать их. Нужно переместить компанию из этапа Аристократизма в период Рассвета (терминология Адизиса). Для этого часто используют гибкие методологии. Но процедура внедрения в них проходит, гораздо сложней и требует куда больших затрат в чем молодых компаниях.
Ну пока вы только подтверждаете мои слова, разве не так?
«Scrum может быть полезен как готовый шаблон который можно легко внедрить»
По сути, это и есть то, что я называю халтурой. Вместо того что бы выработать свою методологию, наиболее подходящую здесь и сейчас, берется готовый шаблон, который гарантировано полностью подходить не будет. Тут бы его как следует доработать бы напильником, но как правило на этом все и останавливается. В итоге — халтура на уровне руководства.
По второму пункту аналогично. И кстати да, я все это знаю. Достаточно бесполезная информация, в действительности не имеющая отношения к делу, особенно поучительная история про горнолыжный курорт.
Конечно никто не знает как разрабатывать ПО. Потому что каждое ПО в каждой команде разрабатывается по разному. Это приблизительно как рисовать картины или делать скульптуры. Только изобразительному искусству гораздо больше лет и они успели понять что подобные попытки на самом деле достаточно бесполезны.
«Scrum может быть полезен как готовый шаблон который можно легко внедрить»
По сути, это и есть то, что я называю халтурой. Вместо того что бы выработать свою методологию, наиболее подходящую здесь и сейчас, берется готовый шаблон, который гарантировано полностью подходить не будет. Тут бы его как следует доработать бы напильником, но как правило на этом все и останавливается. В итоге — халтура на уровне руководства.
По второму пункту аналогично. И кстати да, я все это знаю. Достаточно бесполезная информация, в действительности не имеющая отношения к делу, особенно поучительная история про горнолыжный курорт.
Конечно никто не знает как разрабатывать ПО. Потому что каждое ПО в каждой команде разрабатывается по разному. Это приблизительно как рисовать картины или делать скульптуры. Только изобразительному искусству гораздо больше лет и они успели понять что подобные попытки на самом деле достаточно бесполезны.
Да, но вы говорите уже об опытном руководителе который находится на этапе Ri.
Сорри за копипасту:
Концепцию обучения ShuHaRi, которая пришла из восточных единоборств.
Уровень 1: Shu («подчиняться»)
Изучить базовые правила. Обучение по принципу “Делай то, не делай это”
Уровень 2: Ha («отклоняться»)
Понимание исключений, когда базовые правила не работают. Поиск альтернативных путей и новых техник.
Уровень 3: Ri – («отделяться»)
Перерасти базовые правила, просто жить по основным принципам, не задумываясь.
Я по этому пример со свадьбой и привёл. Женюсь я редко, и готовый шаблон поведения, что там нужно делать мне бы не помешал.
Зачем изучать паттерны проектирования? Ведь каждая система уникальна.
Сорри за копипасту:
Концепцию обучения ShuHaRi, которая пришла из восточных единоборств.
Уровень 1: Shu («подчиняться»)
Изучить базовые правила. Обучение по принципу “Делай то, не делай это”
Уровень 2: Ha («отклоняться»)
Понимание исключений, когда базовые правила не работают. Поиск альтернативных путей и новых техник.
Уровень 3: Ri – («отделяться»)
Перерасти базовые правила, просто жить по основным принципам, не задумываясь.
Я по этому пример со свадьбой и привёл. Женюсь я редко, и готовый шаблон поведения, что там нужно делать мне бы не помешал.
Зачем изучать паттерны проектирования? Ведь каждая система уникальна.
Знаете, я вот женился один раз, но мне не нужны были никакие шаблоны. Можно посмотреть на другие свадьбы и решить что тебе подходит, а что нет. Если вы серьезно для своей свадьбы взяли готовый шаблон, то мне остается лишь посочувствовать вашему воображению.
По той классификации что вы привели, в моем понимании — первые два уровня в принципе не готовы к руководству более чем одним человеком. По мне так совершенно очевидно что руководителем должен быть опытный человек, который уже порядком насмотрелся на то как делать надо, а как не надо и выработал свое понимание рабочих процессов. Конечно, не всегда такой человек в распоряжении есть, а руководитель нужен прямо здесь и прямо сейчас — но в таком случае задача вышестоящего руководителя поддержать человека пока он не дорастет до нужного уровня.
Паттерны проектирования нужно изучать за тем же, за чем методы сортировки. В общеобразовательных целях, не более того. И уж тем более не для того что бы взять потом один конкретный паттерн, и им пытаться потом все написать.
По той классификации что вы привели, в моем понимании — первые два уровня в принципе не готовы к руководству более чем одним человеком. По мне так совершенно очевидно что руководителем должен быть опытный человек, который уже порядком насмотрелся на то как делать надо, а как не надо и выработал свое понимание рабочих процессов. Конечно, не всегда такой человек в распоряжении есть, а руководитель нужен прямо здесь и прямо сейчас — но в таком случае задача вышестоящего руководителя поддержать человека пока он не дорастет до нужного уровня.
Паттерны проектирования нужно изучать за тем же, за чем методы сортировки. В общеобразовательных целях, не более того. И уж тем более не для того что бы взять потом один конкретный паттерн, и им пытаться потом все написать.
На последней свадьбе которой я был, жених забыл купить букетик невесты, и в последний день его покупать было, конечно, весело, но как-то беспокойно :)
Мы вот некоторые паттерны юзаем при разработке нашего продукта, не вижу смысла зачем изобретать велосипед. Не комплектуем от этого особо.
Мы вот некоторые паттерны юзаем при разработке нашего продукта, не вижу смысла зачем изобретать велосипед. Не комплектуем от этого особо.
> Руководителем должен быть опытный человек, который уже порядком насмотрелся на то как делать надо, а как не надо и выработал свое понимание рабочих процессов.
Судя по всему, свои знания он получил с потолка, просто за счет т.н. опыта. То есть когда программист растет и изучает стандартные подходы к разработке — это нормально. А если руководитель начнет делать то же самое, значит он несостоятельный? Откуда же тогда возьмутся опытные руководители, если не будут проходить тот же самый путь СУХАРИ? Как вышестоящий руководитель сможет ему помочь расти? Поделится своим опытом и подчиненный внезапно подрастет?
Для того и нужны стандарты, чтобы на них оттачивать свои умения.
И насчет сравнения с методами сортировки. Разве кому-то удалось обойти безболезненно шаг обучения тривиальным вещам? Разумеется только с их помощью ничего путнего не получится, но в то же время надо уметь ими пользоватся, чтобы не изобретать велосипед каждый раз. А если человек только читал про методологию, но даже не пробовал применять ее на практике, потому что это все равно не сработает, то толку от такого знания? Ну может повыпендриваться на Хабре, рассказывая, что SCRUM это тупой шаблон, и мнегениальному опытному его маловато будет. А когда возникнет реальный проблема и придется искать ее решение, то практического скрамовского опыта ему как раз и не хватит. Возможно, СКРАМ предоставил бы ему технику решения конкретной проблемы, но человек не удосужился ее опробовать раньше или вообще ее не знает. В итоге страдает в первую очередь он сам. Зато у него всегда будет оправдание, что если даже я такой опытный руководитель не справился, то какой-то там СКРАМ и подавно не потянул бы.
Судя по всему, свои знания он получил с потолка, просто за счет т.н. опыта. То есть когда программист растет и изучает стандартные подходы к разработке — это нормально. А если руководитель начнет делать то же самое, значит он несостоятельный? Откуда же тогда возьмутся опытные руководители, если не будут проходить тот же самый путь СУХАРИ? Как вышестоящий руководитель сможет ему помочь расти? Поделится своим опытом и подчиненный внезапно подрастет?
Для того и нужны стандарты, чтобы на них оттачивать свои умения.
И насчет сравнения с методами сортировки. Разве кому-то удалось обойти безболезненно шаг обучения тривиальным вещам? Разумеется только с их помощью ничего путнего не получится, но в то же время надо уметь ими пользоватся, чтобы не изобретать велосипед каждый раз. А если человек только читал про методологию, но даже не пробовал применять ее на практике, потому что это все равно не сработает, то толку от такого знания? Ну может повыпендриваться на Хабре, рассказывая, что SCRUM это тупой шаблон, и мне
Есть некоторая разница между теоретическим изучением и практической реализацией. Изучать паттерны хорошо. Писать чистыми паттернами — плохо. Программист может и должен изучать стандартные подходы в разработке, но применять их не в моем проекте. В любом случае над ним всегда должен стоять опытный руководитель который не даст ему совершать стандартных ошибок, которые стандартным подходам способствуют.
Но есть разница между руководителем и программистом. Опытный программист берется из неопытного, по этому в процессе роста он может себе позволить себе ошибаться, тем более что у него достаточно узкая зона ответственности и его со всех сторон прикрывают — рядом есть товарищи по группе, сверху начальник, сзади контроль качества, спереди мануалы. Его дело маленькое, отвечает он только за свою работу. Именно по этому в проект не берут только неопытных программистов, их всегда стараются прикрыть опытными разработчиками, что бы те их на ходу поправляли.
С руководителем такая штука не прокатывает. Нельзя на проект поставить несколько неопытных руководителей, прикрыв их в этом же проекте опытными. Потому что руководитель должен один быть. И по этому опытных руководителей берут не из неопытных руководителей, а из опытных программистов, или других специалистов, но тоже не менее опытных. По той же причине что я писал выше. Попробуйте найти в объявление «требуется руководитель проекта, можно без опыта работы», это практически нереально, потому что никто в своем уме так делать не будет, если проект хоть сколько нибудь ответственный, или работодатель не считает себя гуру способным распознать настоящий талант с первого взгляда.
Помимо всего прочего, ни скрам, ни какая другая задача не решает проблем. Если ваш проект завалился, то даже применяй ты скрам или что другое, тебе это не поможет. Потому что если он провалился из-за методологии разработки, то ты БЕЗДАРНЕЙШИЙ руководитель. Я видел как проекты вытягиваются просто на самоорганизации, в чистом хаосе, при нормальной команде завалить проект сложно. Заваливаются они или из-за неправильной команды, неправильной бизнес модели(т.е. проект в принципе провальный) или откровенного идиота руководителя. Если считаешь что твой проект прогорел из-за методологии, посыпь голову пеплом и больше никогда не занимайся разработкой, пиши код. И не пытайся лезть выше, ибо просто не твое. Совсем.
Все что может сделать подобраная методология — снизить/повысить издержки, при том не критично. Тут где то рядом писали, что можно вообще менять методологии без всякой логики, производительность будет только расти, просто за счет ковыряния зоны комфорта. Эффективность методологий раздута безбожно.
Но есть разница между руководителем и программистом. Опытный программист берется из неопытного, по этому в процессе роста он может себе позволить себе ошибаться, тем более что у него достаточно узкая зона ответственности и его со всех сторон прикрывают — рядом есть товарищи по группе, сверху начальник, сзади контроль качества, спереди мануалы. Его дело маленькое, отвечает он только за свою работу. Именно по этому в проект не берут только неопытных программистов, их всегда стараются прикрыть опытными разработчиками, что бы те их на ходу поправляли.
С руководителем такая штука не прокатывает. Нельзя на проект поставить несколько неопытных руководителей, прикрыв их в этом же проекте опытными. Потому что руководитель должен один быть. И по этому опытных руководителей берут не из неопытных руководителей, а из опытных программистов, или других специалистов, но тоже не менее опытных. По той же причине что я писал выше. Попробуйте найти в объявление «требуется руководитель проекта, можно без опыта работы», это практически нереально, потому что никто в своем уме так делать не будет, если проект хоть сколько нибудь ответственный, или работодатель не считает себя гуру способным распознать настоящий талант с первого взгляда.
Помимо всего прочего, ни скрам, ни какая другая задача не решает проблем. Если ваш проект завалился, то даже применяй ты скрам или что другое, тебе это не поможет. Потому что если он провалился из-за методологии разработки, то ты БЕЗДАРНЕЙШИЙ руководитель. Я видел как проекты вытягиваются просто на самоорганизации, в чистом хаосе, при нормальной команде завалить проект сложно. Заваливаются они или из-за неправильной команды, неправильной бизнес модели(т.е. проект в принципе провальный) или откровенного идиота руководителя. Если считаешь что твой проект прогорел из-за методологии, посыпь голову пеплом и больше никогда не занимайся разработкой, пиши код. И не пытайся лезть выше, ибо просто не твое. Совсем.
Все что может сделать подобраная методология — снизить/повысить издержки, при том не критично. Тут где то рядом писали, что можно вообще менять методологии без всякой логики, производительность будет только расти, просто за счет ковыряния зоны комфорта. Эффективность методологий раздута безбожно.
> И по этому опытных руководителей берут не из неопытных руководителей, а из опытных программистов, или других специалистов, но тоже не менее опытных.
Вы здесь противоречия не видите? Опытный человек в другой области не обязан обладать практическими навыками в разных методологиях. Теоретическими сколько угодно, он мог даже участвовать в проектах, построенных на той или иной методологии и иметь некоторую практику в этом. Но роль руководителя подразумевает понимание не отдельных элементов, а всей методологии в целом. Опытный не-руководитель такого опыта иметь не может в принципе. Поэтому ему жизненно необходимо такой опыт зарабатывать, а другого варианта кроме как применять стандартное решение поначалу у него просто нет.
С четвертым абзацем согласен — методология не панацея и не оправдание провалу.
Вы здесь противоречия не видите? Опытный человек в другой области не обязан обладать практическими навыками в разных методологиях. Теоретическими сколько угодно, он мог даже участвовать в проектах, построенных на той или иной методологии и иметь некоторую практику в этом. Но роль руководителя подразумевает понимание не отдельных элементов, а всей методологии в целом. Опытный не-руководитель такого опыта иметь не может в принципе. Поэтому ему жизненно необходимо такой опыт зарабатывать, а другого варианта кроме как применять стандартное решение поначалу у него просто нет.
С четвертым абзацем согласен — методология не панацея и не оправдание провалу.
А ничего что основными подопытными кроликами методологий являются собственно программисты? В итоге именно они на самом деле гораздо лучше понимают как эти методологии работают, ибо испытали их на себе. Вы думаете программисту или тем более тимлиду менее понятны результаты внедрения методологии, чем руководителю проекта? Они не разделены фактически ни чем. Более того, лучше всего результаты ощущает тимлид, чем руководитель проекта, ибо он гораздо лучше чувствует команду, и как следствие все особенности взаимодействия, а тимлид по сути — главный программер. По этому никакого противоречия нет.
А вы простите кого предполагаете привлекать к руководству ИТ командой, человека который собственно не имеет значительного опыта в программировании? Как вы себе это представляете?
А вы простите кого предполагаете привлекать к руководству ИТ командой, человека который собственно не имеет значительного опыта в программировании? Как вы себе это представляете?
> Вы думаете программисту или тем более тимлиду менее понятны результаты внедрения методологии, чем руководителю проекта?
Разумеется, руководителю результаты более понятны, потому что это его единственная задача — руководить. А программист в гробу видел все эти методологии, лишь бы дали спокойно работать. Тимлид в зависимости от ситуации может близко к руководителю понимать полный процесс разработки, но от него это опять таки не требуется в такой мере, как от руководителя.
Но даже тимлид остается программистом, главная задача кооторого создавать качественный продукт, а не руководить в полном смысле этого слова. Поэтому от тимлида не требуется тех знаний и просто черт характера, необходимых руководителю. Как следствие, далеко не всякий тимлид может стать хорошим ПМом. А если он все-таки идет в ПМы, то тут-то и начинается обучение с нуля, когда начинаешь смотреть на все под другим углом. И далеко не для всех это безболезненный процесс.
Чтобы руководить ИТ командой нужно понимание предметной области, но это не означает обязательный опыт непосредственно программирования. И даже если он есть, то он ничего не гарантирует.
Разумеется, руководителю результаты более понятны, потому что это его единственная задача — руководить. А программист в гробу видел все эти методологии, лишь бы дали спокойно работать. Тимлид в зависимости от ситуации может близко к руководителю понимать полный процесс разработки, но от него это опять таки не требуется в такой мере, как от руководителя.
Но даже тимлид остается программистом, главная задача кооторого создавать качественный продукт, а не руководить в полном смысле этого слова. Поэтому от тимлида не требуется тех знаний и просто черт характера, необходимых руководителю. Как следствие, далеко не всякий тимлид может стать хорошим ПМом. А если он все-таки идет в ПМы, то тут-то и начинается обучение с нуля, когда начинаешь смотреть на все под другим углом. И далеко не для всех это безболезненный процесс.
Чтобы руководить ИТ командой нужно понимание предметной области, но это не означает обязательный опыт непосредственно программирования. И даже если он есть, то он ничего не гарантирует.
Да, не каждый тимлид может стать ПМом, также как не каждый программист может стать тимлидом, и не каждый тимлид может стать руководителем отдела или директором. Это естественная выборка.
Обучать тимлида руководству проектом с нуля нет никакой необходимости. Тимлид уже умеет управлять своей командой в полной мере, иначе он не тимлид. Все что от него требуется — освоить дополнительные навыки, а именно взаимодействовать с внешним миром не через другого человека, а лично, а руководить командой не непосредственно, а передать эту работу другому. Это не принципиально другая деятельность, это смещение в сторону от текущей. Да, появляется много значительного, и работа другая, но имеющийся у него опыт и определенные способности(по которым и выбрали его повышение) вполне позволят ему прекрасно справляется со своими обязанностями без дополнительного обучения.
Как вы себе представляете руководителя ИТ команды, хорошего, который никогда не программировал? Я видел такую реализацию в жизни, и в лучшем случае это был результат «выше среднего», и то при условии что человек пришел с понижением из смежной области и обладал определенным талантом управления в принципе, в своей области давал отличные результаты. В ИТ — выше среднего и не более. Люди которые не блистают талантами, а просто среднечки — показывают уже в лучшем случае посредственные результаты. ИТ — это не макаронная фабрика, это отрасль обладающая огромным количеством особенностей, и совершенно невозможно эффективно в ней управлять если ты из нее не вырос.
Как вы себе представляете вообще «знание предметной области без опыта» для руководителя ИТ команды? Объяснить ему на пальцах ООП? Управление — это не только понимание технических особенностей(на изучение которых надо потратить очень много времени, а что бы хоть как то реально понять, надо иметь определенный минимум практики). ИТ это не техника, ИТ это люди. Что бы эффективно ими управлять, надо понимать что ими движет, их мотивы, то как они это воспринимают. Если ты сам не вырос из программистов, ты никогда их нормально не поймешь. Можно человеку очень долго объяснять особенности какого нибудь agile, но реально он сможет понять то, как он работает, только поработав хотя бы пару месяцев простым программистом под этой методологией, а потом еще пару месяцев под другой. До тех пор пока этого не произойдет — методологии будут в его голове простой табличкой соотношения плюсов и минусов, без реального понимания процесса. Он почитает статьи в интернете, провести нное количество мероприятий, посмотреть как команда в них поучаствует. Увидеть как команда с них выходит, идет на свои места, и… Дальше происходит магия и на выходе некая часть продукта. Снова меропритие, и снова магия. Для него это будет только некоторой черной коробкой, над которой он производит некоторые действия, а что внутри нее не знает. А самое главное — внутри. Можно конечно понимать что если нажимаешь на газ — машина едет вперед, а переключаешь передачу едет быстрее. Но гонщиком никогда не станешь если не понимаешь физику сцепления, принцип работы двигателя и многое другое, а лучше если еще и своими руками все это поковыряешь. А люди — гораздо сложнее чем машины, теории о том как эта коробочка с магией внутри работает категорически недостаточно.
Обучать тимлида руководству проектом с нуля нет никакой необходимости. Тимлид уже умеет управлять своей командой в полной мере, иначе он не тимлид. Все что от него требуется — освоить дополнительные навыки, а именно взаимодействовать с внешним миром не через другого человека, а лично, а руководить командой не непосредственно, а передать эту работу другому. Это не принципиально другая деятельность, это смещение в сторону от текущей. Да, появляется много значительного, и работа другая, но имеющийся у него опыт и определенные способности(по которым и выбрали его повышение) вполне позволят ему прекрасно справляется со своими обязанностями без дополнительного обучения.
Как вы себе представляете руководителя ИТ команды, хорошего, который никогда не программировал? Я видел такую реализацию в жизни, и в лучшем случае это был результат «выше среднего», и то при условии что человек пришел с понижением из смежной области и обладал определенным талантом управления в принципе, в своей области давал отличные результаты. В ИТ — выше среднего и не более. Люди которые не блистают талантами, а просто среднечки — показывают уже в лучшем случае посредственные результаты. ИТ — это не макаронная фабрика, это отрасль обладающая огромным количеством особенностей, и совершенно невозможно эффективно в ней управлять если ты из нее не вырос.
Как вы себе представляете вообще «знание предметной области без опыта» для руководителя ИТ команды? Объяснить ему на пальцах ООП? Управление — это не только понимание технических особенностей(на изучение которых надо потратить очень много времени, а что бы хоть как то реально понять, надо иметь определенный минимум практики). ИТ это не техника, ИТ это люди. Что бы эффективно ими управлять, надо понимать что ими движет, их мотивы, то как они это воспринимают. Если ты сам не вырос из программистов, ты никогда их нормально не поймешь. Можно человеку очень долго объяснять особенности какого нибудь agile, но реально он сможет понять то, как он работает, только поработав хотя бы пару месяцев простым программистом под этой методологией, а потом еще пару месяцев под другой. До тех пор пока этого не произойдет — методологии будут в его голове простой табличкой соотношения плюсов и минусов, без реального понимания процесса. Он почитает статьи в интернете, провести нное количество мероприятий, посмотреть как команда в них поучаствует. Увидеть как команда с них выходит, идет на свои места, и… Дальше происходит магия и на выходе некая часть продукта. Снова меропритие, и снова магия. Для него это будет только некоторой черной коробкой, над которой он производит некоторые действия, а что внутри нее не знает. А самое главное — внутри. Можно конечно понимать что если нажимаешь на газ — машина едет вперед, а переключаешь передачу едет быстрее. Но гонщиком никогда не станешь если не понимаешь физику сцепления, принцип работы двигателя и многое другое, а лучше если еще и своими руками все это поковыряешь. А люди — гораздо сложнее чем машины, теории о том как эта коробочка с магией внутри работает категорически недостаточно.
> Это не принципиально другая деятельность, это смещение в сторону от текущей.
ПМ-ство — это принципиально другая деятельность, требующая совершенно других знаний и навыков. Видно, из-за разного понимания деятельности ПМа и сыр бор. Я согласен, что для небольших команд на практике разница не столь заметна, чтобы об этом говорить вслух, но она все же есть, и она принципиальная. Иначе получается, что руководителем человек становится просто за счет опыта в другой области (программировании). Это не так, и никогда не было и не будет по-настоящему успешных руководителей, которые считают, что управление проектами это не отдельная дисциплина, а просто что-то само собой приходящее.
> Как вы себе представляете руководителя ИТ команды, хорошего, который никогда не программировал?
Судя по всему вы не в курсе, что кроме собственно программистов ИТ включает еще ряд смежных профессий. Так вот, они есть и люди из их числа с не меньшим успехом могут стать ПМами.
И еще вопрос: зачем ПМу знание ООП?
ПМ-ство — это принципиально другая деятельность, требующая совершенно других знаний и навыков. Видно, из-за разного понимания деятельности ПМа и сыр бор. Я согласен, что для небольших команд на практике разница не столь заметна, чтобы об этом говорить вслух, но она все же есть, и она принципиальная. Иначе получается, что руководителем человек становится просто за счет опыта в другой области (программировании). Это не так, и никогда не было и не будет по-настоящему успешных руководителей, которые считают, что управление проектами это не отдельная дисциплина, а просто что-то само собой приходящее.
> Как вы себе представляете руководителя ИТ команды, хорошего, который никогда не программировал?
Судя по всему вы не в курсе, что кроме собственно программистов ИТ включает еще ряд смежных профессий. Так вот, они есть и люди из их числа с не меньшим успехом могут стать ПМами.
И еще вопрос: зачем ПМу знание ООП?
Принципиально другая деятельность относительно чего? относительно тимлида? Вы серьезно так считаете? В любом более менее серьезном проекте тимлид работает с ПМом в более чем плотной связке, достаточно для того, что бы один другого мог подменить в случае необходимости(также как тимлида может подменить ведущий программист). Если ПМ это принципиально другая деятельность, то в команде ПМ становится не заменяемым сотрудником, с огромным количеством вытекающих отсюда проблем. ПМ принципиально другая деятельность относительно программиста, это факт. Но не тимлида. Да, управление проектами это дисциплина, но не более того, в отличии от программирования, которое является наукой и включает в себя большое количество дисциплин. Более того, тимлид, что бы считаться опытным, и так уже должен ею в той или иной степени владеть, потому что он тоже управляет проектом, просто со своей стороны.
Зачем ООП? а что вы подразумеваете под необходимым ему знанием предметной области, если ООП в него не входит? Умение пользоваться компьютером?
Зачем ООП? а что вы подразумеваете под необходимым ему знанием предметной области, если ООП в него не входит? Умение пользоваться компьютером?
Эту дискуссию можно продолжать долго, но проблема в том, что вы иначе представляете себе роль ПМа, чем я. Для меня ПМ — это в первую очередь управляющий. В понимании Друкера, Листера, ДеМарко, Голдратта и пр. (если вы вдруг не читали, то почитайте, может им вы поверите больше, чем неизвестному мне). ПМ — это человек, отвественный в первую очередь за процессы, и имеющий соответствующие навыки и знания (количество поддисциплин здесь огромное). Ни один из этих навыков не связан с написанием кода напрямую.
Предметная область в данном случае — знание процессов и нюансов разработки ПО. Знание ООП совершенно не обязательно, поскольку за техничесие вопросы отвечает Тимлид, а не ПМ. Поскольку вы мне снова не поверите, то здесь для примера сошлюсь на PMBOK, который описывает все области знаний, необходимые ПМу.
По своему опыту считаю, что на практике навыки программирования часто мешают ПМу, поскольку у него есть огромный соблазн диктовать Тимлиду, что и как надо делать. Из-за этого легко возникает скрытый конфликт между ними.
Предметная область в данном случае — знание процессов и нюансов разработки ПО. Знание ООП совершенно не обязательно, поскольку за техничесие вопросы отвечает Тимлид, а не ПМ. Поскольку вы мне снова не поверите, то здесь для примера сошлюсь на PMBOK, который описывает все области знаний, необходимые ПМу.
По своему опыту считаю, что на практике навыки программирования часто мешают ПМу, поскольку у него есть огромный соблазн диктовать Тимлиду, что и как надо делать. Из-за этого легко возникает скрытый конфликт между ними.
>И да, в ИТ действительно гораздо больше умных людей, и меньше идиотов, но это вовсе не означает что их мало.
Самое хреновое — это не их количество, а тот факт, что каким-то непостижимым образом они стабильно умудряются оседать в районе управляющей верхушки.
Самое хреновое — это не их количество, а тот факт, что каким-то непостижимым образом они стабильно умудряются оседать в районе управляющей верхушки.
«Начальник — дурак» — распространенное заблуждение, просто ты рассуждаешь исходя из имеющейся у тебя картины происходящего, а у него картина несколько иная, плюс разные приоритеты, вот и выходит взаимное непонимание.
>«Начальник — дурак» — распространенное заблуждение, просто ты рассуждаешь исходя из имеющейся у тебя картины происходящего, а у него картина несколько иная
Вот именно, что «картина» начальников зачастую настолько «иная», что не имеет ничего общего не только с моей картиной, но и с объективной реальностью. Но когда начальник на основании этой своей «картины» принимает решение (не слушая при этом, что ему говорят те, кто «в теме»), которое заведомо обречено на провал, а потом удивляется «как же так?», и в результате всё равно делаем так, как ему пытались втолковать, но полгода спустя и бегая как ошпареные, то кто он, если не дурак?
Слава богу, я нашёл компанию (вернее, команду, т.к. в других частях компании может быть совсем по-другому), в которой начальник в технических вопросах слушает технических специалистов (несмотря на то, что он сам в прошлом был программистом, но, разумеется, потерял «хватку» за последние годы).
Вот именно, что «картина» начальников зачастую настолько «иная», что не имеет ничего общего не только с моей картиной, но и с объективной реальностью. Но когда начальник на основании этой своей «картины» принимает решение (не слушая при этом, что ему говорят те, кто «в теме»), которое заведомо обречено на провал, а потом удивляется «как же так?», и в результате всё равно делаем так, как ему пытались втолковать, но полгода спустя и бегая как ошпареные, то кто он, если не дурак?
Слава богу, я нашёл компанию (вернее, команду, т.к. в других частях компании может быть совсем по-другому), в которой начальник в технических вопросах слушает технических специалистов (несмотря на то, что он сам в прошлом был программистом, но, разумеется, потерял «хватку» за последние годы).
1. Как известно, в реальности всё не так как на самом деле, поэтому объективной картины реальности не существует ;)
2. «Дело было обречено на провал» — это случаем не ретроспективное искажение?
3. Имхо дураки встречаются везде, но на каждой следующей ступеньке карьерной лестницы их всё меньше — просто потому, что при естественном отборе побеждает сильнейший (непотизм конечно портит всю эту стройную картину, но хочется верить, что это далеко не главный фактор карьерного роста).
2. «Дело было обречено на провал» — это случаем не ретроспективное искажение?
3. Имхо дураки встречаются везде, но на каждой следующей ступеньке карьерной лестницы их всё меньше — просто потому, что при естественном отборе побеждает сильнейший (непотизм конечно портит всю эту стройную картину, но хочется верить, что это далеко не главный фактор карьерного роста).
>Как известно, в реальности всё не так как на самом деле, поэтому объективной картины реальности не существует
Как известно, человек, обладающий более обширными и более актуальными данными (неважно, в какой области), имеет на порядок больше шансов составить верное суждение по тому или иному вопросу, нежели человек, который «где-то как-то что-то когда-то знал, а чего не знал, то ему Рабинович по телефону напел».
>«Дело было обречено на провал» — это случаем не ретроспективное искажение?
Нет, это мнение специалиста сразу после того, как озвучили задачу, ресурсы, сроки и предполагаемые пути решения.
>Имхо дураки встречаются везде, но на каждой следующей ступеньке карьерной лестницы их всё меньше — просто потому, что при естественном отборе побеждает сильнейший (непотизм конечно портит всю эту стройную картину, но хочется верить, что это далеко не главный фактор карьерного роста).
Поначалу хочется верить, да. Но чем больше компаний/команд пройдёшь, тем вера почему-то всё слабее и слабее.
Фишка в том, что на сугубо технических (исполнительских) позициях на одной болтологии не выедешь — тут нужны знания и умения, а вот на управляющей позиции — да запросто!
Впрочем, это сугубо мой опыт. Возможно, мне так «везло» всё время :)
Как известно, человек, обладающий более обширными и более актуальными данными (неважно, в какой области), имеет на порядок больше шансов составить верное суждение по тому или иному вопросу, нежели человек, который «где-то как-то что-то когда-то знал, а чего не знал, то ему Рабинович по телефону напел».
>«Дело было обречено на провал» — это случаем не ретроспективное искажение?
Нет, это мнение специалиста сразу после того, как озвучили задачу, ресурсы, сроки и предполагаемые пути решения.
>Имхо дураки встречаются везде, но на каждой следующей ступеньке карьерной лестницы их всё меньше — просто потому, что при естественном отборе побеждает сильнейший (непотизм конечно портит всю эту стройную картину, но хочется верить, что это далеко не главный фактор карьерного роста).
Поначалу хочется верить, да. Но чем больше компаний/команд пройдёшь, тем вера почему-то всё слабее и слабее.
Фишка в том, что на сугубо технических (исполнительских) позициях на одной болтологии не выедешь — тут нужны знания и умения, а вот на управляющей позиции — да запросто!
Впрочем, это сугубо мой опыт. Возможно, мне так «везло» всё время :)
Но чем больше компаний/команд пройдёшь, тем вера почему-то всё слабее и слабее.
Хз, у меня тьфу-тьфу, вроде пока наоборот — чем выше позиции тем компетентней сотрудники, хотя менять работу из-за некомпетентного начальника уже, увы, приходилось.
Хз, у меня тьфу-тьфу, вроде пока наоборот — чем выше позиции тем компетентней сотрудники, хотя менять работу из-за некомпетентного начальника уже, увы, приходилось.
Ну внимательнее присмотритесь к другим компаниям. Я например постоянно мониторю состояние внутри целого ряда компаний — во первых что бы просто быть в курсе, во вторых предпочитаю учится на чужих ошибках, а не на своих. В «обойме» есть как действительно хорошие компании, у которых есть чему поучится, так и наоборот. Вам видимо повезло с компаниями. Ну, или может быть вы не обо всем знаете )
Такое тоже имеет место быть, когда речь идет о принятых в отношении тебя решениях, а есть вполне объективные факторы по которым можно сделать этот вывод. К примеру наступление вполне ожидаемых катастрофических последствий принимаемых решений. И я знаю парочку реально клинических случаев и меня это реально удивляет.
Согласен бывает, но чаще сталкивался с ситуацией, когда оценка «дурак» присваивалась из-за банального незнания приоритетов и смежных областей в которых лежали нюансы, основываясь на которых принималось решение, кажущееся «дурацким».
Кстати вот еще интересный факт. Задача руководителя не только поставить задачу, но и объяснить ситуацию. Имхо, у хорошего руководителя должен быть авторитет среди своих сотрудников.
Вообще я честно говоря считаю что во всем всегда виноват руководитель, и чем выше, тем более виноват. Ибо у сотрудников дело маленькое — выполнять поставленные задачи. А вот следить за выполнением, подбирать сотрудников — задача руководителя. Бардак — значит плохая организация. Постоянные косяки — плохо подобраные сотрудники. Рыба как известно гниет с головы, я считаю что справедливо и обратное — если руководство правильное, оно под собой всегда выстроить правильных исполнителей.
Вообще я честно говоря считаю что во всем всегда виноват руководитель, и чем выше, тем более виноват. Ибо у сотрудников дело маленькое — выполнять поставленные задачи. А вот следить за выполнением, подбирать сотрудников — задача руководителя. Бардак — значит плохая организация. Постоянные косяки — плохо подобраные сотрудники. Рыба как известно гниет с головы, я считаю что справедливо и обратное — если руководство правильное, оно под собой всегда выстроить правильных исполнителей.
Кстати да, меня это тоже реально удивляет.
Уважаемый автор, мне как среднестатистическому читателю не нравится эта статья. Lраматическая завязка про культ Карго, переход на IT, а потом извините но «в IT не все дураки». Так нельзя. Я, как читатель, должен понять, что все дураки, а мы, заодно с автором умные — это же одно из ценнейших правил распостранения гербалайфа, фильтров Петрика, телевизионных сериалов и блогов всяческих гур.
Учти автор, нам не нравится когда все вокруг умные, мы следим за тобой…
;)
Учти автор, нам не нравится когда все вокруг умные, мы следим за тобой…
;)
Оффтопик:
Советую посмотреть фильм «Наверное, боги сошли с ума».
Советую посмотреть фильм «Наверное, боги сошли с ума».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Культ Карго в IT — троллим адептов scrum-а