Олексий
к сожалению, адекватной альтернативы слова
коучингна русском нет. найдете — пишите.
к скраму и правда накопилось в индустрии много претензий. но давайте разбираться:
на моем опыте половина из них вызвана просто непониманием самих принципов (это лечится тренингами, отчасти), вторая половина тем, что компании, заявляющие о внедрении скрам, на самом деле не хотят меняться вовсе. и поэтому адаптируют каркас, не понимая, его сути. это опасно.
винить скрам в чем-то по сути бессмысленно и непродуктивно. по своей сути, скрам — это очень леговесный набор правил. целью которого является наладить ряд обратных связей для повышения прозрачности ситуации. это в своей сути все. ничего об оценках, велосити, менеджерах, отчетах, длинных неинтересных совещаниях по грумингу...
есть такая метафора, что скрам — дает зеркало. это так, если его правильно внедрить. без всего мусора, с которым он ассоциируется.
а то, что потом в этом зеркале видны кривые рожи (не примите лично!) — ну да, некомфортно, но ведь они там и раньше были. просто зеркало было замыленным.
так что вреда от скрама быть не может в принципе. как от зеркала. как от обратной связи. как от прозрачности. просто начнут происходить вещи, которые давно должны были случиться. и куча всяких проблем всплывет наружу, но они скорее всего и раньше были.
так, что скрам безопасен, если внедрен опытными людьми (отсюда и вся эта статья о скрам-мастерстве)
безопасен...НО! кроме случаев, когда вместо скрама подается что-то очень кривое с таким же названием. к сожалению, 80% команд и компаний украины если не больше делают скрам очень криво. и это ведет очень часто к наращиванию тех долга, эксплуатации команды, недовольству команд и проч.
вот это и нужно чинить. а не скрам.
по поводу вреда кривого скрама есть есть крутая статья апологета xp по этому поводу: ronjeffries.com/...
разница не очевидная, но есть.
на самом деле есть, как минимум, 4 стиля работы с группой (или человеком):
— фасилитация (применимо только для группы)
— коучинг
— менторинг (наставничество)
— обучение
отличие обучения от коучинга в том, что первое подразумевает, что у клиента нет знаний, и что их нужно дать. коучинг же подразумевает, что у клиента уже есть все необходимое, ему нужно просто поддержать и помочь вопросами открыть для себя ответы.
agile коучинг — это по сути смешение всех приведенных 4 стилей работы, отсюда часто возникает путаница.
ищите дальше. такие проекты-команды-компании есть.
“common sense is not that common” как известно.
вижу в этом мире скопилось много обиженных «скрамом» людей. очень жаль.. и как минимум половина «озлоблённых» (как видно из комментариев) работающий скрам в глаза-то и не видела.
жаль. реально. ибо классная команда, тесно работающая с заказчиком — это прекрасное зрелище.
сходите может в гости в компании, где всё в порядке? поговорите с людьми, у которых есть позитивный опыт?
слелайте что-то с собой толковое. правда.
скептицизм — это вообще хороший знак, знак потенциала для развития.
цинизм же — нет, тупик для мозга.
решать вам.
предоставлять клиенту качественный сервис по разработке ПО
а у вас что, делание успешных продуктов не входит в спектр услуг?
согласен полностью.
но статья о том, как решать проблему уже после сейлов. конечно же, root cause — глубже.
блин. точно!
хотя бы честно. но чести эти делает.
я сожалею о вашем опыте.
если у вас проект на два года, но вы что-то делаете не так.
с троллингом пойди в форум.
зачем платить за то, что делать не нужно?
задачи исполнителя сделать за фиксированный бюджет максимум пользы.
2. да, и это не самая эффективный способ работать над продуктами, если интересует качество, сроки и бюджет.
хотели улучшить всю систему, а в итоге получили набор локальных оптимизаций. это потому что стали мерять людей поодиночке, а не команду в целом.
да, увы, если вы хотите платить за сделанную работу, вам скорее всего придётся научиться оценивать конкретных работников... но, живя в мире, сложных систем, где людям нужно работать слаженными командами для достижения цели, такие парадигмы неприменимы.
людей-то вы может и научитесь оценивать, но влиять таким образом на производительность всей системы производства (системы отношений членов команды) вряд ли сможете предсказуемо.
я не видел успешных реализаций «piece work» работы для команд — оплаты за результат. я бы не пошёл работать в такой проект, думаю. хочу, как и все, стабильные деньги, раз уж я на кого-то работаю.
к тому же такой вид внешней мотивации может сильно ударить по реальной мотивации людей. появится страх, сомнения, нежелание экспериментировать.
Daniel Pink в известной книге «драйв» подробно рассматривает различие между мотивацией рабочих и креативных работников (нас): www.ted.com/...
нужно может тогда растить, а не руководить?
Сергей, ты очень прав.
система может быть сложной:
business заказчика <-> IT заказчика <-> IT подрядчика
в этом случае «IT заказчика» является как бы заказчиком для «IT подрядчика». но это лишь по контракту. реальным же кастомером для подрядчика является «business заказчика» и вот именно с ними и нужно строить мосты путём вовлечения в процесс.
и вот как раз это и есть на мой взгляд чуть ли не самый главным момент, который подрядчик разумный (vendor sapiens) должен вложить в контракт: доступ к телу кастомера.
без этого я не верю в то, что можно делать успешные продукты.
больше денег можно просить всегда, когда клиент доволен.