Надеюсь, на последней фотографии не Ваши сотрудники? :) В противном случае как работодатель Вы сделали грандиозную антирекламу — какой вменяемый человек пойдёт работать в компанию, где процветает ТАКОЙ тимбилдинг? :)
Спасибо за перевод! Что касается самой статьи, то, наверное, из-за тенденции к инфантилизации разработчиков тот момент, когда agile перестанет восприниматься как мир розовых пони, никогда и не наступит. Да и после слов "время цикла увеличивается, а бизнес-ценность уменьшается" уже сразу становится понятно, что ничего дельного дальше не будет. Какая бизнес-ценность? На каком рынке? В деятельности команд какого состава? С каким циклом проекта? И многие другие вопросы. Стремление презентовать "аджайл" как некую универсальную стратегию в отрыве от контекста глубоко ошибочно и приводит к потере денег, увеличению сроков разработке и даже убийству продукта.
То, что Вы озвучили, безусловно воспринимается как явные перегибы и недостаток профессионализма. Однако, с утверждением "играл не за ту команду" я поспорю и не могу пройти мимо Вашего комментария. Менеджер играет не за заказчиков, менеджер играет не за разработчиков, его цель — максимизация прибыли при минимизации издержек. А в этом контексте у указанного руководителя вместо личного непрофессионализма может вполне оказаться грандиозный список требований и вышестоящее руководство с огромным… Хм… хлыстом, скажем так.
Да. Волосы шевелятся от ужаса от описанного в статье. Но все ли так плохо на самом деле? Давайте будем предельно честны: значительная часть заказчиков ставит своей целью не реальный поиск уязвимостей, а всего лишь получение заветной бумажки. А мы при этом с обеих сторон по-прежнему будем делать вид, что "все серьещно", ведь это тоже правила игры.
Все, что будет написано ниже относится не к статье, а исключительно к комментариям на неё. Очень большая ошибка представлять себе управление IT только в контексте "управление разработкой" и "коммуникация через менеджера проекта". Во-первых, менеджер проекта клиента не привлекал. Чтобы у него появился этот заказ поработал совершенно другой блок сотрудников — начиная от директоров и заканчивая маркетологами и всеми теми продавцами, кто ездил на встречи и устанавливал контакты. Во-вторых, не нужно считать разрабатываемую систему продуктом. Продукт — это скорее про выгоды от её использования (не путать с фичами самой системы). И здесь опять же работали другие. В-третьих, если мы говорим не о галере, а о продуктовой компании, то появляется ещё огромный сектор работ. В-четвёртых, продолжать можно вообще долго.
Очевидно, что необходимо контролировать не только результат, но и процесс выполнения работы чтобы следить за общим вектором движения. Очевидно, что не стоит заострять в этот момент внимание на деталях, а стараться доносить до исполнителей стратегию. Но как Вам удаётся при этом соблюсти баланс и не скатываться в микроменеджмент, есть ли какие-то практики кроме условных трех этапов, на которых исполнители получают фидбек? С большим уважением отношусь ко всему, что делает додо, хотелось бы больше деталей.
Спасибо за перевод. Одна из немногих статей, где под словами "технический долг" понимается именно первоначальное значение термина — наличие неоптимальных решений в пользу быстрого внедрения того или иного нового функционала. Одно это делает прочтение статьи истинным наслаждением. Удивительно насколько часто в наше время под "техническим долгом" понимают не вышеуказанные сложности, а банально разросшийся беклог.
Излишняя увлеченность законом Парето приводит к нежелательному результату — человек начинает сосредотачиваться на своих 20% "результативных" задач в ущерб оставшимся 80, в результате же начинает не только развиваться, но и мыслить весьма узко, а к моменту необходимости совершения очередного "разворота" и смены приоритетов оказывается совершенно неподготовленным.
Многое в статье верно, хотя частично и несколько утрировано, однако значительную часть проблем с недостаточным качеством выпускаемого ПО можно объяснить гораздо короче: в цикле "сделайте как-нибудь чтобы работало, а потом уже сделаем хорошо" зачастую не доходит дело до второго этапа, потому что к этому моменту уже требуются новые фичи.
Давайте все же не будем кривить душой относительно ненависти к менеджерам на хабре, как Вы об этом пишете. Интерес к тем или иным практикам стабильно высок, для многих из аудитории ресурса наоборот интересно посмотреть взгляд с той стороны баррикад, а некоторые, как, например, я, когда-то пришли в управление из разработки. Статьи, описывающие "на пальцах" основы управления или элементы методологии всегда пользовались большим успехом и имели и высокие рейтинги, и массу каверзных вопросов в комментариях, а их авторы пользуются уважением со стороны сообщества. Но когда под соусом подачи очередных "n ошибок" человек начинает писать откровенный, простите, бред, то реакция со стороны сообщества логична и ожидаема.
Прочитал статью и вздрогнул. Мне интересно, кому вообще в голову приходит поставить человека с явным синдромом вахтера на позицию, которая подразумевает улучшение коммуникации? Кто предполагает, что работа команды станет лучше, если дать иллюзию полномочий (в статье акцент именно на них, хотя реально их нет) сотруднику, который совмещает новые обязанности с работой инженера? Кто допускает превратить гибкие методологии в цирк, потому что скрам — это стильно, модно, молодежно? Здесь тот случай, когда рыба гниёт с головы, привет руководству Вашей компании и добрый совет — поменяйте подход.
Я не имею ничего против разработчиков, и крайне уважаю их труд, который позволяет нам пользоваться многими благами цивилизации и делает нашу жизнь лучше. Но, согласитесь, если мы говорим о шаблоной работе, банальном кодинге, где речь не идёт ни о решении инженерных задач, ни о необходимости применять мозг, о работе, которую можно загнать в тесные рамки, описанные автором статьи, то речь идёт никак не о высококвалифицированном персонале.
Вы в целом правы, конечно. Поясню, просто у меня обратный Вашему цикл, ROI — не средство для обоснования стоимости своих услуг, а цель. Ну и отдать на аутсорс разработку в продуктовой компании — ну, так себе
Аджайл или аутсорс? Такое же сравнение как, например, осьминог и Везувий. Принципиально разные инструменты под различные бизнес-модели. Что касается ROI, то здесь это универсальный ответ для большинства собственников на вопрос "почему я должен за это платить". Ведь ни для кого, надеюсь, не секрет, что единственное, что интересует владельца бизнеса — это сколько он заработает денег с вложенных?
Наивно предполагать, что "оптимизированные" процессы обязательно вообще запустятся. Оптимизировать можно только с пониманием особенностей бизнеса, с анализом того, почему вообще устроено так, а не иначе, после долгого аудита и при участии всех заинтересованных лиц. Неосторожное внедрение ERP разрушило уже не одни не оптимальные, но эффективные процессы и привело к убыткам.
Надеюсь, на последней фотографии не Ваши сотрудники? :) В противном случае как работодатель Вы сделали грандиозную антирекламу — какой вменяемый человек пойдёт работать в компанию, где процветает ТАКОЙ тимбилдинг? :)
"23 правила запуска ИТ-стартапа с минимальными затратами" или "Как управлять пет-проектом, который не нацелен на рост"
В таком случае могу только согласиться с Вами о конкретно этом случае и порадоваться, что жизнь расставила все по своим местам :)
Спасибо за перевод! Что касается самой статьи, то, наверное, из-за тенденции к инфантилизации разработчиков тот момент, когда agile перестанет восприниматься как мир розовых пони, никогда и не наступит. Да и после слов "время цикла увеличивается, а бизнес-ценность уменьшается" уже сразу становится понятно, что ничего дельного дальше не будет. Какая бизнес-ценность? На каком рынке? В деятельности команд какого состава? С каким циклом проекта? И многие другие вопросы. Стремление презентовать "аджайл" как некую универсальную стратегию в отрыве от контекста глубоко ошибочно и приводит к потере денег, увеличению сроков разработке и даже убийству продукта.
То, что Вы озвучили, безусловно воспринимается как явные перегибы и недостаток профессионализма. Однако, с утверждением "играл не за ту команду" я поспорю и не могу пройти мимо Вашего комментария. Менеджер играет не за заказчиков, менеджер играет не за разработчиков, его цель — максимизация прибыли при минимизации издержек. А в этом контексте у указанного руководителя вместо личного непрофессионализма может вполне оказаться грандиозный список требований и вышестоящее руководство с огромным… Хм… хлыстом, скажем так.
Да. Волосы шевелятся от ужаса от описанного в статье. Но все ли так плохо на самом деле? Давайте будем предельно честны: значительная часть заказчиков ставит своей целью не реальный поиск уязвимостей, а всего лишь получение заветной бумажки. А мы при этом с обеих сторон по-прежнему будем делать вид, что "все серьещно", ведь это тоже правила игры.
Все, что будет написано ниже относится не к статье, а исключительно к комментариям на неё. Очень большая ошибка представлять себе управление IT только в контексте "управление разработкой" и "коммуникация через менеджера проекта". Во-первых, менеджер проекта клиента не привлекал. Чтобы у него появился этот заказ поработал совершенно другой блок сотрудников — начиная от директоров и заканчивая маркетологами и всеми теми продавцами, кто ездил на встречи и устанавливал контакты. Во-вторых, не нужно считать разрабатываемую систему продуктом. Продукт — это скорее про выгоды от её использования (не путать с фичами самой системы). И здесь опять же работали другие. В-третьих, если мы говорим не о галере, а о продуктовой компании, то появляется ещё огромный сектор работ. В-четвёртых, продолжать можно вообще долго.
Очевидно, что необходимо контролировать не только результат, но и процесс выполнения работы чтобы следить за общим вектором движения. Очевидно, что не стоит заострять в этот момент внимание на деталях, а стараться доносить до исполнителей стратегию. Но как Вам удаётся при этом соблюсти баланс и не скатываться в микроменеджмент, есть ли какие-то практики кроме условных трех этапов, на которых исполнители получают фидбек? С большим уважением отношусь ко всему, что делает додо, хотелось бы больше деталей.
Спасибо за перевод. Одна из немногих статей, где под словами "технический долг" понимается именно первоначальное значение термина — наличие неоптимальных решений в пользу быстрого внедрения того или иного нового функционала. Одно это делает прочтение статьи истинным наслаждением. Удивительно насколько часто в наше время под "техническим долгом" понимают не вышеуказанные сложности, а банально разросшийся беклог.
Излишняя увлеченность законом Парето приводит к нежелательному результату — человек начинает сосредотачиваться на своих 20% "результативных" задач в ущерб оставшимся 80, в результате же начинает не только развиваться, но и мыслить весьма узко, а к моменту необходимости совершения очередного "разворота" и смены приоритетов оказывается совершенно неподготовленным.
Многое в статье верно, хотя частично и несколько утрировано, однако значительную часть проблем с недостаточным качеством выпускаемого ПО можно объяснить гораздо короче: в цикле "сделайте как-нибудь чтобы работало, а потом уже сделаем хорошо" зачастую не доходит дело до второго этапа, потому что к этому моменту уже требуются новые фичи.
Удивительно! А как быть со словами в родственных языках, которые близки по написанию, но различны по семантике? Не портит ли это модель?
А некоторым нравится слово "Афиша" :)
Давайте все же не будем кривить душой относительно ненависти к менеджерам на хабре, как Вы об этом пишете. Интерес к тем или иным практикам стабильно высок, для многих из аудитории ресурса наоборот интересно посмотреть взгляд с той стороны баррикад, а некоторые, как, например, я, когда-то пришли в управление из разработки. Статьи, описывающие "на пальцах" основы управления или элементы методологии всегда пользовались большим успехом и имели и высокие рейтинги, и массу каверзных вопросов в комментариях, а их авторы пользуются уважением со стороны сообщества. Но когда под соусом подачи очередных "n ошибок" человек начинает писать откровенный, простите, бред, то реакция со стороны сообщества логична и ожидаема.
Прочитал статью и вздрогнул. Мне интересно, кому вообще в голову приходит поставить человека с явным синдромом вахтера на позицию, которая подразумевает улучшение коммуникации? Кто предполагает, что работа команды станет лучше, если дать иллюзию полномочий (в статье акцент именно на них, хотя реально их нет) сотруднику, который совмещает новые обязанности с работой инженера? Кто допускает превратить гибкие методологии в цирк, потому что скрам — это стильно, модно, молодежно? Здесь тот случай, когда рыба гниёт с головы, привет руководству Вашей компании и добрый совет — поменяйте подход.
Я не имею ничего против разработчиков, и крайне уважаю их труд, который позволяет нам пользоваться многими благами цивилизации и делает нашу жизнь лучше. Но, согласитесь, если мы говорим о шаблоной работе, банальном кодинге, где речь не идёт ни о решении инженерных задач, ни о необходимости применять мозг, о работе, которую можно загнать в тесные рамки, описанные автором статьи, то речь идёт никак не о высококвалифицированном персонале.
Вы в целом правы, конечно. Поясню, просто у меня обратный Вашему цикл, ROI — не средство для обоснования стоимости своих услуг, а цель. Ну и отдать на аутсорс разработку в продуктовой компании — ну, так себе
Аджайл или аутсорс? Такое же сравнение как, например, осьминог и Везувий. Принципиально разные инструменты под различные бизнес-модели. Что касается ROI, то здесь это универсальный ответ для большинства собственников на вопрос "почему я должен за это платить". Ведь ни для кого, надеюсь, не секрет, что единственное, что интересует владельца бизнеса — это сколько он заработает денег с вложенных?
Спасибо за пример.
Наивно предполагать, что "оптимизированные" процессы обязательно вообще запустятся. Оптимизировать можно только с пониманием особенностей бизнеса, с анализом того, почему вообще устроено так, а не иначе, после долгого аудита и при участии всех заинтересованных лиц. Неосторожное внедрение ERP разрушило уже не одни не оптимальные, но эффективные процессы и привело к убыткам.