Стыд и Скрам, часть вторая

Публикация № 1021217

Управление - Управление проектом

20
Крик души про иллюзию внедрения Agile. Продолжаем разговор про сложности, с которыми мы сталкиваемся, когда под видом гибких технологий используются "топорные" директивные методы. По сути, мы в очередной раз сталкиваемся с извечным конфликтом "сурового менеджмента" и "творческих разработчиков"

Продолжение публикации: Стыд и скрам - Чему нас учит Scream Guide

За время, прошедшее с публикации на Инфостарте моей статьи “Стыд и Скрам”, хороший человек Владимир Меркушев не поленился и перевел Scream Guide-целиком. За что спасибо ему большое. Говорят, многие руководители проектов, читая это руководство, даже всплакнули - настолько больные темы. 

Сегодня я хочу поговорить про команду разработчиков и планирование спринта, как его описывает Scream Guide - опять же, под лозунгом "в каждой шутке есть доля шутки, а все остальное - правда..." Слева приведены цитаты из первоисточника (Scrum Guide), справа - из пародии (Scream Guide), а снизу - мои комментарии.

Команды Разработки обладают рядом характеристик: Команды Разработки обладают рядом характеристик:

• Они самоорганизующиеся: никто (даже Скрам-мастер) не может указывать Команде Разработки как превратить Бэклог Продукта в готовые к релизу Инкременты. 

• Они кросс-функциональны: команда обладает всеми навыками, которые необходимы для создания Инкремента Продукта. 

• Скрам не признает подкоманд в Команде Разработки, независимо от областей, над которыми необходимо работать (например, тестирование, архитектура, эксплуатация или бизнес-аналитика). Это правило не имеет исключений. 

• Команда Разработки несет коллективную ответственность за создание Инкремента Продукта. При этом отдельные члены Команды Разработки могут обладать различными специализированными навыками и экспертизой. 

 

  • Они называются «самоорганизующимися». Любой (даже уборщик) может рассказать команде разработчиков, как они должны делать свою работу;

  • Команды разработчиков проводят большую часть своего времени, открывая новые и инновационные способы игр с метриками, придуманными руководством

  • Команды разработчиков называются «кросс-функциональными» и обладают практически всеми необходимыми навыками для создания «почти готового» продукта;

  • Scream делит команду на фракции и подгруппы, например, тестирование, архитектура, бэкенд или бизнес-анализ, чтобы еще больше запутать выполняемую работу;
  • Отдельные члены команды разработчиков могут не иметь требуемых навыков, но ответственность в любом случае лежит на них.

 

 


Если серьезно...

KPI проекта
 Во-первых, про игры с метриками - увы, часто больная тема, особенно в крупных компаниях. Могу только процитировать Максима Дорофеева: 
Для любой системы KPI существует такая стратегия B, что показатели KPI при следовании этой стратегии находятся в зеленой зоне, но при этом сам проект через **пу идет в неизвестность. 

 

Во-вторых, про "почти готово". Я думаю, что всем автоматизаторам знакома ситуация “почти готового” продукта, пребывающего в таком состоянии длительное время… У меня над столом даже висит один из моих любимых афоризмов: “Не так страшны первые 90% работы, как ее вторые 90%...”
По моему опыту, один из бонусов Agile - это фокус внимания именно на доделывании до конца. Потому что именно при выпуске в продакшн мы понимаем, будет ли тот или иной инструмент рабочим. Потому что гибкие методы - они в первую очередь про умение учиться на своих ошибках. И когда мы не видим законченный результат, не видим те проблемы и сложности, с которыми столкнулись реальные пользователи при практическом применении продукта - вот эта возможность учиться на ошибках как раз уходит...

 

Стадии реакции на проблему

Во-третьих, про ответственность. 
Психология выделяет следующие стадии реакции человека на проблему. Начинаем мы, обычно, с первого уровня, и двигаемся дальше, если обратная связь от мироздания в ответ на нашу реакцию, нас не устраивает. 

  • Первая стадия - Отрицание. “Ничего не было, я в домике!!! Нет никакой проблемы, всё работает, это вам просто показалось”.
  • Вторая стадия - Обвинение. “Мне сказал (менеджер, тимлид, пользователь, аналитик - нужное подчеркнуть, недостающее вписать) так сделать, он и виноват, я-то тут причем?
  • Третья стадия - Оправдание. “Ну я же хотел как лучше!” (а по другому и быть не могло)
  • Четвертая стадия - Самообвинение. "Ну вот я такой фиговый разработчик. Увольте меня.”
  • Пятая стадия - Обязательства. “Обещаю больше никогда таких ошибок не совершать!”
  • И только шестая стадия - Ответственность. Как чувство собственности за результат, и искреннего желания исправить то, что произошло. 

(Вспомните притчу про Орлов, Устриц и Уток от Бодо Шефера - вот шестая стадия - это как раз и поведение Орла, который стремится достичь цели, а не Утки, которая только крякает).

Поэтому если проблему легко свалить на менеджера или еще кого-то - то стадия Ответственности заведомо не наступит, незачем, хватит Обвинения!
 

 

 

 

Отмена спринта 

Отмена спринта
  • Спринт может быть отменен досрочно. Право на отмену Спринта имеет только Владелец Продукта, хотя на данное решение могут повлиять заинтересованные лица, Команда Разработки или Скрам-мастер. 
  • Существует единственное основание для отмены Спринта — потеря актуальности Цели Спринта. Причиной этому могут быть смена направления работы компании, изменения рыночных условии или технологии. То есть Спринт может быть отменен, если он потерял смысл в контексте сложившихся обстоятельств. Но подобные отмены происходят крайне редко благодаря короткой длительности Спринтов. 
  • Отмена Спринта требует много усилий и ресурсов, так как предполагает переориентацию всех участников, чтобы начать новый Спринт и его Планирование. Отмены Спринта болезненны для Скрам-Команды, поэтому к ним прибегают крайне редко. 
  • Спринт может быть отменен до истечения временного интервала Спринта. Только менеджер имеет право отменить спринт, даже если команда и владелец продукта уже знают, что они не добьются успеха. Владелец продукта может быть козлом отпущения за это решение, принятое их менеджером или менеджером этого менеджера — или менеджером менеджера этого менеджера — ну, вы поняли идею. 
  • Спринт отменяется, если менеджер чувствует, что команда не выполняет его указания. Это может произойти, если разработчики начнут думать самостоятельно или если менеджер изменит свое мнение. В общем, Спринт должен быть отменен всякий раз, когда менеджер чувствует себя неуверенно. Из-за короткой продолжительности Спринтов, отмена является эффективным механизмом для создания неуверенности и беспорядка в команде.
  • Когда Спринт отменяется, все выполненные и «готовые» элементы бэклога отправляются в корзину. Частично «готовые» элементы возвращаются в случайном порядке в бэклог. Частично выполненную работу лучше оставить в ветках разработчиков и задокументировать в вики, чтобы возобновить её когда-нибудь.
  • Отмена Спринта — отличный способ держать команды занятыми, так как все собираются и начинают планирование следующего Спринта. Отмена спринта часто задевает команду за живое, что делает её отличным инструментом для снижения самооценки и доверия внутри команды.


Если серьезно...

 

То здесь мы опять поднимаем вопрос ответственности. Когда у команды есть понимание, что происходит, и уверенность в завтрашнем дне - люди работают плодотворно. Большинство руководителей проектов сходятся в том, что для высокопрофессиональных разработчиков недостаточно денежной мотивации, определяющим фактором является получение удовлетворения от работы, видимость результата. И отмена Спринта - и следующие за ней вышеупомянутые неуверенность и беспорядок в команде - это самый надежный способ вот этого чувства удовлетворения от работы избежать. 

 

Планирование Спринта Планирование Спринта
  • Задачи, над которыми будет трудиться Команда Разработки во время Спринта, определяются на Планировании Спринта. План создается совместными усилиями всей Скрам-Команды. 
  • Планирование Спринта ограничено по времени. Для Спринта длительностью один месяц Планирование не должно занимать более 8 часов. Если Спринт короче, то и Планирование проводится быстрее. 
  • Скрам-мастер убеждается, что событие состоялось, а участники понимали его цель. Скрам-мастер обучает Скрам-Команду соблюдать временное ограничение. 
  • По результатам Планирования Спринта Скрам-команда решает: 
    • каким будет Инкремент в конце Спринта; 
    • как организовать работу, чтобы получить готовый Инкремент Продукта. 
  • План командной работы в течение Спринта создается на Планировании Спринта. Этот жесткий план создается заранее владельцем продукта или руководством, не привлекая команду, чтобы не отвлекать её от выполнения работы. Максимальное время для планирование Спринта длиною в месяц — 8 часов. Этого времени вполне достаточно, чтобы успокоить команду и убедить в реальности абсолютно нереального плана.

  • Задача Scream мастера гарантировать проведение Планирования, и убедиться что каждому будет назначено достаточно работы. Также он учит Scream команду не задавать слишком много вопросов при представлении работы.
  • Присутствие менеджера во время Планирования Спринта очень важно, чтобы гарантировать, что получены ответы на следующие критические вопросы:
    • Сколько заданий назначено каждому человеку?
    • Что займет сколько времени?
    • Все ли ресурсы полностью использованы?
    • Если дела пойдут неожиданно хорошо, какую дополнительную работу вы можете ещё сделать?
  • По мере необходимости менеджер прекращает бессмысленные дискуссии о сути задач бэклога и их технической реализации и переориентирует членов команды разработки на задачи, которые им необходимо взять в работу. Менеджер может передать эту ответственность Scream мастеру.
  • В конце планирования спринта Scream мастер должен заставить членов команды взять на себя обязательство выполнить все свои задачи, даже если все знают, что дополнительные задачи будут добавляться на протяжении всего Спринта.


Если серьезно...

В ходе онлайн “Базового курса для руководителей ИТ-проектов” который я веду сейчас на Инфостарте, мы собрали основные преимущества от привлечения команды к планированию. Получился вот такой список (дополняйте, у кого еще есть что сказать?) 

  • Руководитель не обладает всеми компетенциями по работам проекта (программистам виднее, сколько займет время программирование)
  • Уровень владения информации по проекту повышается у членов команды
  • Разные взгляды позволяют получить более объективную картину
  • Конечный Исполнитель должен взять на себя ответственность за результат и затраты - это достигается совместным планированием

В моей практике работы и консультирования самых разных компаний, довольно явным маркером того, что что-то в команде/организации идет не так являлся фокус внимания не на результат, а на занятость и использование ресурсов. Настоящий Scrum как раз призывает от этого уходить. Нам не важно, сколько времени мы затратили на “почти готовый” продукт - важно, какой результат мы получили!

 

Scream

 

 

Поделитесь вашим опытом! С какими проблемами сталкиваетесь на практике?
 

В статье цитирую перевод Владимира Меркушева Scream Guide. Как быть Agile и не меняться и текст Scrum Guide с официального сайта.

 

20

См. также

Специальные предложения

Сталкивались ли вы с проявлениями Scream Guide в своей практике?


Как про нас написано... Так и живем. (27.78%, 5 голосов)
27.78%
Часть проблем знакома (38.89%, 7 голосов)
38.89%
Изредка сталкиваемся (5.56%, 1 голосов)
5.56%
Нет, ничего подобного не бывает (11.11%, 2 голосов)
11.11%
Не пробуем применять гибкие методы, поэтому вопрос не актуален (16.67%, 3 голосов)
16.67%

Комментарии
Избранное Подписка Сортировка: Древо
1. user1048024 14.03.19 21:44 Сейчас в теме
Немножко из другой темы, но в принципе о том же

https://infostart.ru/public/1020673/

https://infostart.ru/redirect.php?url=aHR0cDovL29kZXNza2l5LmNvbS96aHZhbmV0c2tpeS10b20tMy9wYXJv­dm96LWRsamEtbWFzaGluaXN0YS5odG1s

"Если серьезно..."

"Руководитель не обладает всеми компетенциями по работам проекта (программистам виднее, сколько займет время программирование)" - паровоз для машиниста? Кто принимает "проектное" решение? Кто обладает большей компетенцией, "опытом"? В данном случае "Руководитель" это не руководитель "Команды разработчиков"?
"Уровень владения информации по проекту повышается у членов команды"
- команда это все кто участвует - это же не только "программисты"?
"Разные взгляды позволяют получить более объективную картину"
- чем больше информации, тем объективней "картина" - чем больше "следов", тем легче найти "криминалисту " "преступника"
"Конечный Исполнитель должен взять на себя ответственность за результат и затраты - это достигается совместным планированием"
- тут смешиваются ЛПР и "советник" - обмениваться " впечатлениями" могут все - принимает решение"за результат и затраты" конкретный "Исполнитель" - ЛПР - пришлите мне пару лимонов :) в личку укажу куда :) возьмёте на себя такую ответственность за результат и затраты?
Чтобы иллюзий стало меньше - есть "технология" "Стыд и Скрам" и есть реальное их "применение" - Принцип неопределённости Гейзенбе́рга, но в экономике
5. MariaTemchina 575 15.03.19 09:51 Сейчас в теме
(1)
Про ссылку на Жванецкого - спасибо, познавательно.
Кто принимает "проектное" решение? Кто обладает большей компетенцией, "опытом"? В данном случае "Руководитель" это не руководитель "Команды разработчиков"?

Еще раз: совместно принятое решение - это более действенно, чем лично принятое соло руководителем.
Но вообще, по Agile не рекомендуется делать проекты, предполагающие кардинальные изменения архитектуры.
6. sergathome 15.03.19 10:05 Сейчас в теме
(5) С чего бы это размазывание ответственности вдруг стало эффективнее персональной ? Это прям какое-то новое слово в управлении...
Irwin; w.r.; +2 Ответить
7. MariaTemchina 575 15.03.19 10:07 Сейчас в теме
(6)
С чего бы это размазывание ответственности вдруг стало эффективнее персональной ? Это прям какое-то новое слово в управлении...


Это очень хороший вопрос! Коллеги, поделитесь - кому удается добиться того, что команда ощущает коллективную ответственность, и за счет чего это получается?
Слава; Winstoncuk; +2 Ответить
8. sergathome 15.03.19 10:16 Сейчас в теме
(7) Команда может ощущать всё, что угодно. Но это всё что угодно никогда не будет эффективнее персональной ответственности каждого. Но для этого нужен качественный менеджмент... И тут мы приходим, (о, какой сюрпрайз!) к выводу, что за всеми тн "гибкими технологиями" скрывается попытка оправдать отсутствие качественного менеджмента ! :))

ps или попытку работать в условиях отсутствия такового, ага
sevushka; CheBurator; Winstoncuk; oldcopy; w.r.; +5 Ответить
12. w.r. 165 15.03.19 13:56 Сейчас в теме
(8)
тн "гибкими технологиями" скрывается попытка оправдать отсутствие качественного менеджмента

Собственно scrum это про "программист большой, ему виднее". Типа программисты настолько умные, что сами могут царствовать и управлять, только в реальности это ни разу не так. Программисты довольно часто ловят звезду и им кажется, что море по колено. Я думаю scrum - это оттуда
Winstoncuk; sergathome; +2 Ответить
13. sergathome 15.03.19 13:59 Сейчас в теме
(12) король реально голый. как на любом трупаке наплодилось мух коучей и прочих жЫвотных... ;))
eskor; w.r.; +2 Ответить
9. acanta 47 15.03.19 11:18 Сейчас в теме
(7) Команда ощущает коллективную ответственность если партком поддерживает решения исполкома.
DDA4746; sergathome; +2 Ответить
10. dmitrydemenew 84 15.03.19 11:22 Сейчас в теме
(7)Я считаю, что если Руководитель не обладает необходимыми компетенциями по работам проекта и не готов брать на себя полную ответственность за его реализацию, то проект, с большой вероятностью, обречен на провал. Потому, что проект с коллективной ответственностью - как автомобиль в котором у каждого окна водитель с собственным рулем. Должен быть только один координатор проектных работ, отвечающий за конечный результат и управляющий всеми участниками проектной группы. Мне пришлось участвовать в нескольких проектах с разделенной ответственностью и коллективным принятием решений - к сожалению, не могу назвать это удачным опытом.
user675041_start2011ruslan; eskor; unichkin; Winstoncuk; oldcopy; +5 Ответить
14. oldcopy 118 15.03.19 13:59 Сейчас в теме
(10)
Я считаю, что если Руководитель не обладает необходимыми компетенциями по работам проекта и не готов брать на себя полную ответственность за его реализацию, то проект, с большой вероятностью, обречен на провал. Потому, что проект с коллективной ответственностью - как автомобиль в котором у каждого окна водитель с собственным рулем.


Если за проект отвечает более одного человека - то виноватых не найти. "Коллективная ответственность", "совместно принятые решения" - это все хорошо, красиво и модно ровно до тех пор, пока все идет хорошо. Как только возникают какие-то проблемы, терки с заказчиком или иные подводные камни - то коллективная ответственность тут же превратится в коллективную безответственность, особенно если нужно принимать непопулярные решения.


(7)
Коллеги, поделитесь - кому удается добиться того, что команда ощущает коллективную ответственность, и за счет чего это получается?


Мне кажется, что это что-то из области мифов и легенд. Что выступает стимулом для принятия на себя ответственности? Вера в светлое будущее? Светлое будущее на хлеб не намажешь. Словами про цель, команду и т.п. еще можно как-то "вдохновить" 20-летних юнцов, но человек с семьей и обязательствами на такое не поведется.

Цели достигаемые командой - это прежде всего цели бизнеса, которые могут существенно расходится с целями конкретного сотрудника. И как справедливо замечено, мотивация не обязательно может быть денежной. Доход хорошего специалиста может быть вполне достаточный, зато, скажем, летом он хочет больше времени проводить с семьей. Какой резон ему брать ответственность и вытягивать забуксовавший проект? Тем более, что с коллективным подходом в принятии решений буксовать он может вечно.

Проблема последних 10% наоборот требует принятия кардинальных решений и возможно даже некоторого конфликта с заказчиком. Так как сложность этих 10% кроется буквально в мелочах. Когда заказчик говорит: все хорошо, но вот тут надо немножечко поправить, а вот сюда кое-что добавить и т.д. и т.п. А если с обоих сторон "коллективная ответственность", то такая ситуация может принять устойчивую форму.

Не очень давно был у нас такой проект, разрабатывали отраслевое решение для медицины. Все шло хорошо, пока проект не вышел на финиш и не пошли замечания от врачей. Обычно они сводились к тому, что все хорошо, но вот здесь надо сделать "немного иначе", причем у каждого врача было свое видение этого "иначе".

Руководитель проекта со стороны заказчика медиком не был и только пожимал плечами, мол им виднее. Поэтому было принято решение и заказчику было доведено, что мы не будем продолжать работу над проектом до тех пор, пока с их стороны не будет назначен ответственный специалист с которым и только с которым мы будем обсуждать изменения, а со своими коллегами пусть он сам находит общий язык.

После такого назначения проект был завершен в две недели. Первую неделю главврач, который взял на себя руководство, еще пытался играть с коллегами в демократию, а потом просто стукнул кулаком по столу и сказал, что как он решит - так и будет. Быстро согласовали доработки, выполнили, сдали и остались довольны друг другом.
pfilyk; eskor; dachnik; user623969_dusa; sergathome; +5 Ответить
17. MariaTemchina 575 15.03.19 15:01 Сейчас в теме
(14)
Проблема последних 10% наоборот требует принятия кардинальных решений и возможно даже некоторого конфликта с заказчиком. Так как сложность этих 10% кроется буквально в мелочах. Когда заказчик говорит: все хорошо, но вот тут надо немножечко поправить, а вот сюда кое-что добавить и т.д. и т.п. Поэтому было принято решение и заказчику было доведено, что мы не будем продолжать работу над проектом до тех пор, пока с их стороны не будет назначен ответственный специалист с которым и только с которым мы будем обсуждать изменения, а со своими коллегами пусть он сам находит общий язык.


Знакомая история! Вы сейчас описали роль, которую в Agile принято называть "Владелец продукта". Он отвечает за содержание работ, что делаем, что не делаем. И да - вы правильно заметили, что важно чтобы он был единой точкой входа, определяющей все работы.
Но это про состав работ, а не про выполнение!...
29. Слава 15.03.19 19:20 Сейчас в теме
(7)
команда ощущает коллективную ответственность, и за счет чего это получается?

Когда участники команды вовлечены в процесс принятия решения - появляется коллективная ответственность.
Эта ответственность не заменяет персональную целиком и это не противоположность, а дополнение.
30. oldcopy 118 15.03.19 19:53 Сейчас в теме
(29)
Когда участники команды вовлечены в процесс принятия решения - появляется коллективная ответственность.


Здесь возникает вопрос, а кем в итоге принимается решение? Командой? Если решение принимают все - то это значит что его не принимает никто. И появляется не "коллективная ответственность", а коллективная безответственность.

Всегда нужен руководитель, который может принять решение и нести за него персональную ответственность. Это не значит, что он не должен и не будет прислушиваться к мнению команды, но именно он должен выслушав все варианты и точки зрения принять решение, которое впоследствии станет обязательным для всех участников команды.
43. DDA4746 18.03.19 13:53 Сейчас в теме
(30) Когда-то давным-давно наблюдал, как это работает.

На предприятии было 2 очень хороших технических спеца - главный инженер (теоретик, конструктор) и начальник эксплуатации (практик). Технические проблемы на пересекающихся сферах решали у директора (опытный руководитель, но не тех.специалист в конкретной отрасли).
В ходе обсуждения директор молчал и давал спецам выговориться, поспорить, а вмешивался только когда они начинали переходить с конструктива на личности: еще раз формулировал тезисы каждого, просил их подтвердить, и принимал окончательное решение.

На мой взгляд, это лучший вариант "вовлечения в процесс команды", который сочетается с единоличным принятием решения и ответственностью за него (ответственные назначались тут же, контроль - на директоре).
39. Rico17 29 17.03.19 06:51 Сейчас в теме
(7) За счет разделения "предмета ответственности" по компетенциям участников команды в прямой зависимости от рабочей ситуации. Это общее положение. А конкретика всегда конкретна ;)
Ну например, если от клиента пришел чувак бить морду за "криво пришитые рукава", то с ним общается обаятельная девица от группы консультантов... ;)
Дальше работа администратора команды - "награждения непричастных и наказания невиновных"
Следующим выступает "невиновный", который в зависимости от сложившейся ситуации получает общую (неформально-командную) оценку своей невиновности и на конкретных условиях исправляет ситуацию.
Главным в такого рода подходах является насколько команда - КОМАНДА. А это прямая ответственность руководителя. Поскольку за результат ВСЕГДА отвечает (от слова ответственность) руководитель (как бы ему под разными предлогами не хотелось этого избежать).
42. sergathome 17.03.19 19:44 Сейчас в теме
(39) ещё раз - вспоминаем, что эджайл предполагает организацию команд (трайбов, ага) по принципу заказчик [- аналитик] - исполнитель, что ПОЛНОСТЬЮ РАЗРУШАЕТ ....
44. vasily.ovodkov 18.03.19 15:49 Сейчас в теме
(7)Коллеги, добрый день. По поводу коллективной ответственности - мне кажется, это явление уже сложившейся команды. Первый шаг - срабатывание команды, второй - выращивание общей цели, и как следствие - коллективная цель и коллективная ответственность.
2. w.r. 165 15.03.19 08:06 Сейчас в теме
Команда Разработки несет коллективную ответственность за создание Инкремента Продукта.


Если отвественность коллективная, почему тогда зарплату не платить тоже не отдельным людям, а всему коллективу и пусть ее сами между собой делят. Только потом все друг с другом пересрутся и утопия со "срамом" закончится развалом коллектива и убытками компании
Winstoncuk; +1 Ответить
3. oldcopy 118 15.03.19 09:24 Сейчас в теме
Руководитель не обладает всеми компетенциями по работам проекта (программистам виднее, сколько займет время программирование)


Мне тут вспоминается закон Паркинсона, который гласит: Работа заполняет все отведенное для нее время.
dachnik; w.r.; +2 Ответить
4. MariaTemchina 575 15.03.19 09:48 Сейчас в теме
(3)
Мне тут вспоминается закон Паркинсона, который гласит: Работа заполняет все отведенное для нее время.

Это хитрый нюанс. Когда все (включая руководителей, разработчиков и заказчиков) работают в тесном контакте, то в большей степени видно, когда люди работают и дают реальный результат, а когда дурака валяют и имитируют бурную деятельность...
11. w.r. 165 15.03.19 13:47 Сейчас в теме
(4) Как правило у знающего специалиста выполнение аналогичной задачи занимает в десятки и сотни раз мньше времени, чем у неопытного. И знающий может на визуальный взгляд работать меньше, позволяя себе расслабиться. Для этого мы и получаем опыт
sergathome; +1 Ответить
15. sergathome 15.03.19 14:02 Сейчас в теме
(11) Более того, вот, например, сейчас, я пишу здесь, но это не значит, что я не работаю. "Потом Штирлиц проснётся ... " (с) ыыыы
16. w.r. 165 15.03.19 14:10 Сейчас в теме
(15) Интересно узнать мнение Марии на этот счет. Возможно это всего лишь иммитация
sergathome; +1 Ответить
18. MariaTemchina 575 15.03.19 15:03 Сейчас в теме
(15)
(16)
Возможно это всего лишь имитация

На эту тему полезно почитать книжку Брукса "Мифический человекомесяц". Комментарии на профессиональном форуме, конечно, не относятся непосредственно к выполнению работ. Но конструктивной работы у специалиста обычно получается 4-6 часов из 8-ми часового рабочего дня, никто не может заниматься разработкой непрерывно - технически не получается...
19. sergathome 15.03.19 15:16 Сейчас в теме
(18) А я считаю, что в творческих профессиях невозможно чётко разделить работу и неработу. Поэтому попытки управлять этим - шарлатанство как оно есть. ;) Кстати научный термин "конструктивной" вообще требует отдельного описания ;)

ps Единственный способ работы в таких видах деятельности это персонифицированные договора с как можно более точным описанием желаемого результата, включая сроки его получения. Никаким скрамом тут и не пахнет.
20. MariaTemchina 575 15.03.19 15:50 Сейчас в теме
(19)
Единственный способ работы в таких видах деятельности это

Коллега, я все-таки призываю к меньшей категоричности! С фразой "Действенный способ работы" - более чем согласна, о да!! С фразой "Единственный способ работы" - никак нет.
22. w.r. 165 15.03.19 17:14 Сейчас в теме
(20) можете работать неэффективно, срывая сроки и не получая результат в конце. Тоже ведь работа так то
sergathome; +1 Ответить
23. acanta 47 15.03.19 17:16 Сейчас в теме
(22) а хорошо это или плохо?
sergathome; +1 Ответить
24. w.r. 165 15.03.19 17:19 Сейчас в теме
(23) конечно хорошо, особенно для заказчика
sergathome; +1 Ответить
33. sergathome 16.03.19 15:07 Сейчас в теме
"Комманд Ком мертв, а мы еще нет!" - пели, обнявшись, отец Виндоуз и
командир Нортон. (с)
34. sergathome 16.03.19 16:18 Сейчас в теме
(20) съедобный сорт всегда один - высший
21. w.r. 165 15.03.19 17:12 Сейчас в теме
(19) конструктивным может быть исправление одной строки кода за минуту. Только человек должен знать, где эта строка находится и что она делает. А это уже квалификация и опыт
sergathome; +1 Ответить
35. sergathome 16.03.19 16:22 Сейчас в теме
(21) молодЕж забыла этот анекдот, про телевизор, мастера, и, 10 рублей. Истории, УВЫ, свойственно повторяЦЦО !

ЗЫ и кое-кто, на этом, всегда...
25. oldcopy 118 15.03.19 17:22 Сейчас в теме
(18)
никто не может заниматься разработкой непрерывно - технически не получается...


Любой работой нельзя заниматься непрерывно в течении 8 часов рабочего дня, чисто технически или скорее физиологически, нужно периодически делать перерыв. Для работников интеллектуального труда можно переключиться на что-то другое. Два-три часа работаем, потом полчаса отвечаем на почту, пишем комменты на профессиональном форуме и т.д. и т.п. Потом возвращаемся со свежими силами.

Но тут главное не перегнуть палку, если сотрудник начинает отвлекаться каждые полчаса - то это уже ненормально и можно говорить о том, что форум стал мешать работе. Хотя это во многом индивидуально.

Долгая фокусировка на задаче часто мешает посмотреть на нее под другим углом. Как иногда бывает: решаем какую-то проблему пять минут, час, полтора - уперлись в тупик. Пошли выпили кофе, почитали чего нибудь и вдруг приходит понимание, что все это время мы долбились головой в стену, в то время как за углом есть калитка.
sergathome; +1 Ответить
26. acanta 47 15.03.19 17:39 Сейчас в теме
Это если решать задачу. А если искать выход из положения то задача вообще ни при чём.
27. Yashazz 2334 15.03.19 18:27 Сейчас в теме
А, ещё один крик души про эйджил... Болтовня на ровном месте вокруг надувания щёк с умным видом... Иллюзия систематизации работы, ага...
eskor; sergathome; +2 Ответить
36. sergathome 16.03.19 16:41 Сейчас в теме
(27) вокруг ага. ага. а они кажуть - мы хоть пытаемся..
37. acanta 47 16.03.19 16:46 Сейчас в теме
(36) само ничего не систематизируется (с) Карл Линней
sergathome; +1 Ответить
38. sergathome 16.03.19 16:57 Сейчас в теме
(37) хыхы, некто Маркс, Энгельс и, страшно подумать, Муссолини с ним нифига бы не поспорили...
28. Yashazz 2334 15.03.19 18:29 Сейчас в теме
Первую неделю главврач, который взял на себя руководство, еще пытался играть с коллегами в демократию, а потом просто стукнул кулаком по столу и сказал, что как он решит - так и будет. Быстро согласовали доработки, выполнили, сдали и остались довольны друг другом.

Вот она, единственная правда жизни. Есть волевой кулак - будет успешное внедрение. Нет такого - будет жевание соплей, конфликты и проблемы. И никкакие хитропопые технологии планирования работ не оказывают на это ни малейшего влияния. Ни ма-лей-ше-го.
eskor; dachnik; sergathome; +3 Ответить
31. user1048024 15.03.19 21:56 Сейчас в теме
(28) (30)
И скрам ли тут был, или скрим до того, действительно абсолютно неважно, если есть осмысленное компетентным ЛПР решение - "Есть волевой кулак - будет успешное внедрение", ну или "волевой кулак" - только его разрушит, ведь не всем повезёт с главврачом, и отрицательный результат послужит всем наукой? И чем дальше мы погружаемся в тему, тем больше удаляемся от первоначальной постановки вопроса верить ли в новые методики- "Крик души про иллюзию внедрения Agile", или это про компетенцию заявляющих что они её придерживаются? Картинка со скрамом подозрительно напоминает каскад, итерацию, спираль. И в любом подходе "фокус внимания" подразумевает наличие положительного результата, а иначе как, завтра должно быть лучше, чем вчера. Ну и как мне кажется мнения "главврача" мы тут не услышим?
32. oldcopy 118 15.03.19 22:07 Сейчас в теме
(31)
И скрам ли тут был, или скрим до того, действительно абсолютно неважно, если есть осмысленное компетентным ЛПР решение - "Есть волевой кулак - будет успешное внедрение", ну или "волевой кулак" - только его разрушит, ведь не всем повезёт с главврачом, и отрицательный результат послужит всем наукой?


Но в этом случае мы все равно получим какой-либо результат. Даже и отрицательный. Если проект не пошел - то важно его своевременно завершить и зафиксировать убытки, а не пытаться оживить сдохшее, выбрасывая на ветер деньги и время.

"Коллективная ответственность" грозит же превратить проект в вечные 90%, когда постоянно что-то где-то доделывается, переделывается и исправляется. Особенно если в проекте возникнут какие-либо проблемы. Есть старая поговорка, которая как никогда подходит к данному случаю: у победы много отцов, поражение всегда сирота.
40. Rico17 29 17.03.19 07:32 Сейчас в теме
Я понимаю желание автора на скрам- хайпе заработать очков.
Но при всем положительном эффекте не стоит "пудрить коллегам моск" - скрам - это один возможных способов ТЕХНОЛОГИИ работы команды (это "внутренний" процесс отдела разработки).
А хайп идет вокруг управленческих, кадровых, мотивационных и прочих подходов.
Возникает опасная ситуация, когда руководители соответствующих подразделений перекладывают свою ответственность - НЕ компетентность на "новые импортные технологии разработки" :(
С таким же успехом можно это делать в отношении новых "клавиатур и мышек" )))
eskor; dachnik; w.r.; sergathome; oldcopy; +5 Ответить
41. sergathome 17.03.19 19:32 Сейчас в теме
(40) К огромному сожалению всё гораздо хуже. Так называемые "гибкие технологии разработки" ака скрам, эджайл анд соу он, разрушают само понятие "внутренний процесс" ж))
46. Vladimir Litvinenko 1592 18.03.19 17:03 Сейчас в теме
(41) Потому что это не технологии и не методологии, а набор ограничений, правил и, если повезёт, культуры. Любой внутренний процесс тоже включает в себя набор ограничений и правил. Никаких противоречий нет, просто некорректное использование терминологии, что всегда случается когда терминология проходит через масс-культуру и превращается в товар и "волшебную таблетку".

К тому же постоянно мешается продуктовый и проектный подход. Поэтому задаётся вопрос "Как же при этом соблюсти сроки?", а не "Как нам неизменно и непрерывно поставлять работоспособный продукт на протяжении всей разработки?". Конечно, на некорректный вопрос нет ответа. Например ответ на другой вопрос "Когда мы получим следующую работоспособную версию продукта с оговоренным инкрементом, которую сможем передать потребителям?" ответ будет простым - "В конце этого спринта (1-4 недели)".

Подходы и цели разные и инструменты по идее должны быть разные. Зачем применять продуктовый подход, если делаем не продукт (для внутреннего или внешнего пользователя), а проект, и критерием успеха является соответствие обозначенным на старте полгода назад срокам и бюджету?

https://www.youtube.com/watch?v=0Dj7TDXCEm4
MariaTemchina; sergathome; +2 Ответить
45. acanta 47 18.03.19 15:52 Сейчас в теме
Чем отличается коллективная ответственность в школе от коллективной ответственности в институте?
В школе тех, кто слишком хорошо успевает "награждают" занятиями с теми, кто "совсем не учится" в свободное от занятий время (вместо хобби и футбола необходимо "зажечь" алгеброй или тригонометрией).
В институте эта "премия" за хорошие конспекты и посещаемость снижается до СМС во время экзамена двух-пяти "звездочек" на группу.
Но вот мотивация другая. За помощь в школе баллы (или рейтинг в глазах учителя) добавляются, а в институте за то же самое могут и отчислить за компанию.
MariaTemchina; +1 Ответить
Оставьте свое сообщение