37 идей-мыслей для бюро переводов из книги «Scrum. Революционный метод управления проектами»

Перечитать эту книгу меня пнул Андрей Дроздов, аудитор из KPMG, в дружеской беседе на FB. Я тогда брякнул, что прочитал её, но на самом деле, я скорее пробегал ее глазами и не нашел ничего особо для себя интересного, т.к. мои интересы были далеки от управления командами. Кроме того, мне не понравился перевод (обычное дело ;-).

Сейчас, после изучения канбана на Toyota, же эта книга вызвала у меня гораздо больше любопытства — я сравнил обе методологии и должен сказать, что Scrum для бюро переводов подходит лучше, чем канбан, и уж тем более, чем классическая «водопадная» модель.

Как обычно, рецензии на книги я писать не мастак, поэтому просто выписал 37 цитат-мыслей, которые врезались в память:

1. На исправление ошибки, обнаруженной в день, когда она была сделана, уходил час. Спустя три недели требовалось уже двадцать четыре часа.
2. Командная динамика хорошо функционирует только в малочисленных группах. Классический вариант — семь человек, плюс или минус еще двое. Мне встречались прекрасно работающие группы, состоявшие всего из троих человек.
3.  …сложность не в том, чтобы решить, чего ты хочешь достичь, — намного труднее понять, что ты можешь выполнить.
4. Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше
5. … процесс производства должен быть быстрым и бесперебойным… Все, что мешает его непрерывности, классифицируется как потери.
6. Хотите оказать быструю услугу заказчику? Тогда берите требование с наивысшим приоритетом, выполняйте его — и, полностью сделав, демонстрируйте клиенту.
7. Если кто-то проявил инертность, на это следует немедленно реагировать.
8. Скрам-мастер задает каждому участнику группы три вопроса. Что ты делал вчера, чтобы помочь команде завершить спринт? Что ты будешь делать сегодня, чтобы помочь команде завершить спринт? Какие препятствия встают на пути команды? Всё.
9. В ФБР остановились на двухнедельных циклах исходя из предположения, что в конце каждого этапа они будут иметь полностью функционирующую часть программы…
10. Многочисленной группе понадобится в пять раз больше времени, чем малочисленной.
11. Команда собирается каждый четверг. Разработчики просматривают объемный «бэклог», то есть список отобранных задач, которые нужно решить: от разработки дизайна панели приборов до проверки работы поворотников. Они определяют приоритетность задач, а потом говорят, глядя на этот список: «Ну ладно, и сколько задач мы можем выполнить за эту неделю?» Под «выполнить» подразумевается действительно сделать — как следует и до конца.
12. Каждая команда «А» сформирована таким образом, чтобы все ее члены были разносторонними мастерами боевой подготовки, что позволяет им выполнять операции от начала до конца. Бойцы спецназа постоянно проводят обучение взаимозаменяемости по нескольким специальностям.
13. Минимально жизнеспособный продукт следует представить публике как можно раньше! … минимально жизнеспособный продукт обеспечивает вас обратной связью.
14. …каждый участник группы Scrum тоже должен знать, что делают все остальные. Сиюминутное задание; неизбежные трудности; неожиданные озарения — любая деталь рабочего процесса должна быть прозрачна для всей группы.
15. Чем раньше вы начнете показывать продукты заказчикам, тем быстрее они сообщат вам, делаете ли вы то, в чем они заинтересованы.
16. Компания GM предупредила, что рабочие завода ужасны, но управляющие отличные и их стоит нанять снова. Вместо этого Toyota не спешила приглашать на работу старое руководство, а вот рабочих вернула почти всех, некоторых даже отправила в Японию изучать производственную систему Toyota. Завод NUMMI практически сразу стал собирать автомобили с той же точностью и таким же низким уровнем брака, как и в Японии. Люди остались теми же — поменялась система.
17.  …скрам-мастер несет ответственность за ту часть проекта, которая отвечает на вопрос как делать, а владелец продукта — за ту часть, которая отвечает на вопрос что делать.
18. Планировать полезно. Слепо следовать плану — глупо.
19. Основная забота скрам-мастера — вести команду к непрерывному совершенствованию и регулярно искать ответ на вопрос «Как нам делать еще лучше то, что мы уже делаем хорошо?».
20. Люди счастливы не потому, что успешны. Они преуспевают, потому что счастливы.
21.  …прежде чем расставлять по приоритету дела в списке задач, определитесь с персонажем, пользователем, клиентом — тем человеком, который будет использовать то, что вы собираетесь производить. Вам нужно знать, что ему нравится, чего он терпеть не может, о чем мечтает, что вызывает вдохновение, от чего расстраивается, что приносит радость.
22. Пакет пожеланий одного пользователя часто называют эпопеей …она включает в себя множество фрагментов — мелких пользовательских сценариев, работающих на одну общую идею.
23.  … восемьдесят процентов успеха и ценности любой программы заложены в двадцати процентах ее функциональных возможностей.
24. Вместо того чтобы пытаться создать нечто с одним центральным мозгом, он придумал робота, у которого каждая конечность — всего их шесть — обладала собственным мозгом. Процессор находился в спинном хребте робота и функционировал по нескольким простым правилам: ходить вперед, ходить назад, конечности не должны сталкиваться.
25. Как получается, что меньше работая, успеваешь делать больше? На первый взгляд в этом нет логики. Скотт говорит, что люди, трудясь из последних сил, начинают совершать ошибки, которые, как мы уже знаем, иногда труднее и дольше исправлять, чем все сделать правильно с первого раза. Уставшие сотрудники становятся рассеянными и склонны отвлекать окружающих. Кончается тем, что они принимают неверные решения.
26. …все команды уникальны и неповторимы. У каждой свои темп и ритм работы. Подгонять их под общий шаблон — верный путь в пропасть.
27. …как только команда утверждает список требований, задачи из этого списка «блокируются». Никто не имеет права их менять или вносить добавления.
28. «…люди важнее процессов;
    фактическая работа продукта важнее документации, фиксирующей, что и как продукт должен делать;
    сотрудничество с заказчиком важнее обсуждения условий договора с ним;
    реакция на изменения важнее следования первоначальному плану.»
29. Все работают на один результат и имеют одно видение общей цели: создать реальную ценность как можно быстрее.
30. Никто не распределяет заданий сверху — команда самостоятельна и все решает сама.
31. Смысл составления бэклога представляет создание максимально полного перечисления требований, предъявляемых к функциям продукта. … в списке полно заданий, до которых у вас никогда не дойдут руки, но вам требуется выбрать те, что принесут наибольшую пользу при наименьшем риске.
32. … вместо того чтобы планировать все заранее, дорабатывайте план на протяжении всего проекта.
33. Владелец продукта решает, какой быть концепции проекта, и отвечает за его разработку; несет ответственность за составление и ведение бэклога; собирает и формулирует пользовательские требования, определяя их приоритетность.
34. Планируйте ровно столько, сколько нужно, чтобы ваши команды были всегда заняты.
35. Владелец продукта должен быть всегда доступен для команды, поскольку в любой момент может потребоваться его объяснение, почему то или иное задание нужно делать в первую очередь.
36. Если лучшая группа могла справиться с задачей за неделю, то сколько времени, на ваш взгляд, уйдет на ту же задачу у худшей? Страшно выговорить, но им пришлось потратить две тысячи недель. Вот как велика разница между лучшими и худшими коллективами.
37. Те же люди. Такой же дом. Такая же работа. Вдвое больше времени и вдвое больше денег. Разница заключалась в одном: сосед не использовал Scrum… Мастера работали без согласования друг с другом и были вынуждены ждать, когда закончатся одни работы, чтобы приступить к другим. В результате соседу ремонт обошелся в два раза дороже, причем, по сути, платил он за ожидание.

На момент публикации этого списка дешевле всего купить ее в МИФе (280 руб.), чуть подороже — в Литресе (350 руб.).

С уважением,
Евгений Бартов,
переводчик, копирайтер, маркетолог,
руководитель ГК «Альянс ПРО»