Менеджер: Дайте грубую оценку (хотя бы порядок) времени который это займет (просто, чтобы я ориентировался)?
Сколько? 5-6 месяцев? А почему так долго?

День 15

Менеджер: Как мы обсуждали это может занять порядка 150 дней.

День 30

Менеджер: Это займет около 150 дней.

День 45 (начало проекта)

Менеджер: Вот план, который я составил, с разбиением на этапы. Как и планировалось, мы вкладываемся в 150 дней (даже запас остается). Естественно мы будет постоянно следить насколько план реалистичен и в случае необходимости мы обновим план.

День 90

Менеджер: Ребята, мы отстаем от плана. Обязательно нужно поднажать.

День 150

Менеджер: Мы обязаны выполнить наш коммитмент. Все сроки уже давно озвучены высшему менеджменту, продукт ожидают заказчики.

День 210

Менеджер: Блин. Мы вылезли уже из всех сроков, а у нас дай бог готова 70%. Что будем делать? У кого есть какие идеи?

День 240

Менеджер: После совещания с остальными менеджерами, было принято решение – сдвинуть сроки. Мы ДОЛЖНЫ закончить проект через 80 дней. Но на этот раз нам нужно дать твердый коммитмент.

День 300

Менеджер: (Радостным голосом) Идем по плану, буквально с небольшим отставанием.

День 320

Менеджер: (молчит и напряженно барабанит по клавиатуре)

День 360

Менерджер: Отлично. Проект закончен. Все хорошо поработали. У нас тут следующий проект на подходе. Да, кстати, мне нужна очень грубая оценка, сколько это может занять (просто, чтобы я ориентировался).

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

Но, я собственно не о том. Меня смешат три вещи в их письмах

а) Письма не по теме.

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

б) Письма о том, что должность находится за тридевять земель.

Условно говоря, когда предлагают позицию скажем Team Lead на Аляске. Это конечно прекрасно, но опять же в резюме четко написано, что переезжать я не собираюсь.

в) Письма без указания ценового диапазона.

Это пожалуй уже скорее бесит, чем смешит. Приходит, список требований длинной в страницу с кучей пунктов где нужен опыт 10+ лет и т.п.

Естественно, людей которые обладают даже частью умений этого списка – мало и они вполне таки востребованы.

С требованиями у них все хорошо. И еще какая-нибудь фраза будет – вы будете работать в хорошой компании, над интересных проектом (причем пишут это все). А вот про зарплату молчок.

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

Ну и спрашивается, какого черта вы морочите мозги? Ну, хотите дешевых разработчиков, укажите потолок зарплаты и не трать не свое время, ни время посредника, ни время собеседуемого.

Вроде все просто, есть грязная микроволновка. Многим она неприятна, так как все хотят разогревать еду в чистой микроволновке, но каждый отказывается ее мыть, так как остальные не особо хотят присоединяться.

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

Приходит новый человек, смотрит и говорит… «Блин, ну нельзя же так люди, ну давайте вместе будем мыть микроволновку. Если каждый это будет делать раз в 3 месяца, то она постоянно будет общая чистыми усилиями». В ответ все молчат. Человек вместо широковещательного сообщения начинает подходить к людям по отдельности и люди ему начинают рассказывать, почему мыть микровоклновку они не хотят – один ей редко пользуется, другой не считает это своей обязанностью, третий обижен на весь мир, что ему раньше никто не хотел помогать мыть и поэтому он теперь не собирается это делать и так далее.

В определенный момент, новый человек махает рукой и решает сам ее мыть. Моет раз… моет два… моет три. И вот тут происходит переломный момент.

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

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

Как мне кажется ситуацию а) можно расшевелить активностью. А вот ситуацию б) невозможно изменить изнутри, только обладаю властью в такой ситуации, можно вывести ее из клинча.

Кстати, чем очень опасна ситуация б), тем что новый человек после определенного время битвы с вязким болотом, решает, ну их всех, будут держать в чистоте свой маленький мирок. И собственно говоря, пожив в таком режиме достаточно долго, он сам переходит в разряд «поменьше проиграть».

Кстати, еще раз упомяну о блоге «Психология IT«, тема точно по тематике их сайта..

В общем за этот год у меня слегка сместились акценты, так как познакомился с кое чем новым. Я успел поработать с одной self empowered командой и это был очень интересный опыт.

Собственно команда сильно отличается от других вот чем:
а) Костяк команды очень профессиональный. Умные, ответственные, активные, ищущие новые знаний люди с большим опытом. То, к чему я привык, это когда дай бог 10-20% таковы,
а остальные либо неопытны, либо не слишком мотивированны, либо малоактивны.
б) VP engineering’а похоже ставил цель сбор именно такой команды. И на данный момент он позволяет команде принимать множество достаточно важных решений, которые зачастую в других компаниях принимались бы им или кем-то из top management’а.
в) В момент набора новых людей идет тщательный отбор тех, кто по духу подходит в команду.

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

Соответственно, базируясь на том, что я увидел, слегка изменилось и мое отношение к манифесту. В хорошем случае, действительно нужно очень тщательно выбирать людей и собирать такую команду. А манифест по большему счету рассчитан на плохой случай (краткосрочное сотрудничество, сотрудничество с контракторам, или очень жесткие финансовые ограничения не позволяющие взять лучших людей).

Представим себе, что у нас есть достаточно большой проект (ну скажем на 9 месяцев, на пару десятков человек). Такой, вполне настоящий проект.

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

Уже эта статистика само по себе дело интересное, но в целом, похожие данные можно таки найти и сейчас (не в этом идея). Да кстати, еще заметка, само собой разумеющееся,
что для разных проектов и команд, соотношения куда ушло время будет очень разным (но это так, к делу относится мало).

Что мы делаем дальше, по окончанию проекта, это стираем все артефакты (код, документацию, баг треккер, систему контроля версий, whiteboard’ы). В общем стираем ВСЕ, кроме
памяти людей и заставляем их выполнить еще раз проект, снова записывая время. И это повторяется, пока числа не стабилизируются.

И вот, что мне было бы ОЧЕНЬ интересно поглядеть график. По вертикали – время потраченное на каждую часть, по горизонтали номер повторения. Что-то типа вот такого:

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

Ну и второй график, который интересно было бы глянуть, все то же самое, только не просто стираются все артефакты, но еще и меняются все люди на проекте, кроме самого главного.

Двери должны закрываться в трех случаях:
а) Человек хочет чтобы ему не мешали сосредоточиться (то есть он в комнате один)
б) У людей митинг и его громкость может мешать окружающим.
в) Обсуждаются что-то связанное с финансами (зарплатами, деньгами в банке и т.п.)

Фактически все остальное должно обсуждаться так, чтобы это не было секретом.

«Теперь понятно, почему у нас в Харькове, да и в Украине вобщем, большинство девелоперских фирм имеют головной офис в США, скажем. Ибо разница в зп = 2к$ у нас и 6к$ там (для сеньора) достаточно велика, притом что качество кода не думаю, что сильно отличается. Как в рекламе: «Если нет разницы – то зачем платить больше?» »

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

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

А вот по остальным пунктам, таки пройдусь:

а) Езда по накатанной колее

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

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

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

б) Местные программисты быстрее реагируют на изменение направления.

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

в) Знание языка.

Когда оффшорный программист живет на остравах умпы-лумпы и изъясняется на очень ломанной версии английского и коммуницировать приходится только через менеджера/лида (в оффшорном офисе), у которого с английским получше, но, тем не менее, все равно ломанный, то становится достаточно сложно проверить уровень понимания того, что нужно сделать.

г) Бухгалтерия

Само собой, платить только местным гораздо проще, чем платить и местным и не местным (особенно если за рубежом именно полноценный офис).

д) Иллюзия контроля

Часто менеджер должен видеть, что программист с напряженным видом сидит с 9 утра до 6 вечера, чтобы чувствовать, что программист трудится . А когда кто-то на другом континенте приходит и уходит неизвестно когда, то возникает вопрос о контроле.

Сразу скажу, что чувство контроля тут абсолютно иллюзорно, но тем не менее куча менеджеров очень полагаются именно на иллюзорность.

е) Решение проблем заказчиков.

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

ж) Боязнь кражи интеллектуальной собственности

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

Ну и теперь, возвращаемся к Scrum’у.

1) Один из тезисов Scrum’а состоит в том, что все что нужно – это дать команде самоорганизовать и она станет максимально эффективной. Вот скажите мне, если нанять 10 забулдыг, которые компьютер в жизни не видели, будет ли какой-то эффект от их самоорганизации? Ok, а если дать возможность 10 junior’ам самоорганизоваться, то станут ли они от этого вдруг производить высококачественный код и хорошо разбираться в архитектуре?

Так, вот, то что быстро всплыло в комментариях к прошлой статье – это то, что SCRUM должен хорошо работать на идеальных людях. Да, если есть команда отличных профессионалов, с хорошим опытом, умных, добрых и честных и единственное, что им не давало работать гнетущий их подлец и мерзавец менеджер, то действительно, убрав менеджера и дав им самим организоваться вдруг станет все лучше. А с другой стороны, если они все такие добрые и умные, то думаю и большинство других методологий покажет себя неплохо.

То есть, возникает вопрос. Какова должна быть команда, чтобы эффективность от самоорганизации хорошо прыгнула вперед. Где собственно описание того, на какой команде наиболее эффективно работает SCRUM, вопрос того, как нанять такую команду или что делать с текущей командой, для того, чтобы сделать из нее такую, на которой все будет хорошо работать? Об всем это Scrum скромно молчит.

2) Продолжаю тему команды. Все члены команды считаются team member’ами. Разделения между Dev и QA не проводится. Как вы понимаете, это происходит только на бумаге. QA не может эффективно делать Dev работу, а Dev не может эффективно делать QA работу. Почему мне не слишком нравиться эту ситуация, когда на бумаге одно, а в реальности другое? В такой ситуации значит, что хотели сказать что-то другое, но говорить напрямую было бы неприлично и поэтому мысль замаскировали. Так вот, мысль которую я хотели сказать (да и в сказали таки в многих местах), что Dev + QA __коллективно__ ответственны за проект и не имеют право валить на кого-то другого вину за неправильное или плохое исполнение.

Честно говоря, я не супер большой любитель коллективной ответственности. Опять же, это продолжение пункта N1. Коллективная ответственность хорошо работает на умных, добрых и ответственных людях и она может дать ооочень
плохие результаты (гораздо хуже чем при waterfall management’е) при безответственных и злонамеренных людях.

3) В прошлой статье я написал пример о том, что проект который уже ведется тяжело переводить на Scrum. Я с него и продолжу.

Итак ситуация такова, есть продукт с плохим (или средним) кодом, у этого продукта нету никаких тестов (ни unit, ни ui и ничего другого). А также этот продукт уже активно используют заказчики достаточно часто находя в нем баги (скажем несколько за неделю). Эти баги менеджеры очень хотят пофиксить быстрее, так как заказчики капризные и могут и нафиг послать. Ситуация естественно типична не для все фирм, но для множества продуктовых фирм.

Тут есть две проблемы – одна как работать с багами (которую я опишу тут) и вторая, как выпускать новые версии, которую я опишу в следующем пункте.

С багами можно работать тремя методами
а) Мы таки их по ходу включаем в Sprint. Обычно это учитывают с помощью focus factor (мы называли overhead). В целом работать может неплохо, если багов немного. Как только багов становится много (например команда тратит 30-60% от каждого sprint’а на них), то начинаются проблемы с тем, что sprint’ы становятся слишком непредсказуемы.
б) Можно команду разделить на Scrum – те, кто работают над новым и на support (которые будут работать по какой-то другой методике).
в) Можно таки попытаться откладывать баги на потом и планировать их по честному в следующий Sprint. Сразу скажу, что менеджмент и customer support будет против.

Тут в целом ничего военного, но тем не менее, в классическом описании Scrum’а – об этой проблеме не написано.

4) Когда команда работает над проектом с плохим кодом и без автоматизации тестирования, очень остро становится вопрос, как же сделать так, чтобы в конце Sprint’а можно было отдать заказчикам продукт. Проблема заключается в том, что для того чтобы отдать продукт нужно не просто протестировать 2 новые фичи, которые были сделаны, а еще регрессионно протестировать весь продукт, чтобы проверить ничего ли не было сломано.

Опять же решений несколько:
а) Отдельно от Scrum сидит команда тестировщиков, которые постоянно гоняют регрессионные тесты (до тех пор пока не будет достаточно количество автоматизированных и unit test’ов. Замечу, чаще всего обнаруживается, что QA очень сильно не хватает и нужно нанимать дополнительных людей (что не всегда по душе менеджменту).
б) Таки в конце sprint’а продукт не является shippable. И раз в 3-4 sprint’а таки делают большое перетестирование и пофикс багов. В результате получается скорее модифицированный waterfall, чем Scrum.

И моя стандартная фраза в этой статье – «Как обычно об этом тоже молчит Scrum»

Продолжение следует…

- Как технарь и программист, я очень не люблю, когда мне говорят «делай только так, потому что так правильно» и при этом не объясняю почему именно так правильно, что будет если сделать не так. А все книги по SCRUM’у так и делают – выдают набор практик, артефактов, ролей и т.п., которые нужно использовать без малейшего объяснения для чего нужна каждая из этих деталей.

- Второе, что меня нервирует, это метод «Не думайте об обезьяне» . Пропагандисты практики Scrum, в случае если Scrum сработал в новой компании причисляют это к победам Scrum’а, если же он не сработал обвиняют исполнителей Scrum’а, в том что они не поняли дух и букву Scrum’а и все делали неправильно.

Собственно эти две вещи и заставили меня копнуться чуть глубже. Ну и плюс, за последние полтора-два года, которые я работал в нескольких модификация SCRUM’а у меня накопилось некоторое количество (отрицательного) опыта.

Сразу замечу, что в этой серии статей я не буду давать обзор SCRUM. Если вы с ним не знакомы, то загляните в описание на wikipedia, а еще лучше найдите и почитайте книжку.

Приступим.

1) Передел территорий

Большинство SCRUM книг начинается с того, что рассказывается о том, какие есть роли в SCRUM’е и как надо начинать работать над проектом (составить backlog, перетасовать его по приоритетам и т.п.). Я не видел еще фактически ни одного источника, которые предлагает как «продать» идею внутри компании. В лучшем случае там пишется: Вася, CTO компании, решил попробоывать SCRUM.
Ну да ладно, умный человек всегда может выбрать с десяток пунктов, по которым SCRUM лучше waterfall и залив их большим количеством меда протолкнуть идею попробовать SCRUM в компании. Хотя и это было бы как-то описать, так как зачастую Вася не CTO в компании, а программист/тим лид/менеджер и соотвественно ему таки приходится пропихивать идею наверх.

Интересное начинается дальше. До тех пор пока SCRUM не стартован или только стартуется, все идет мягко и хорошо. Но вот возникает момент когда обнаруживается что
а) Project manager со всем своим длинным послужным списком PMP сертификатов не нужен, а нужен человек который прочел одну книжку и прошел двухдневный семинар Scrum мастерства. И не дай бог роль Scrum Master’а отдадут не Project Manager.
б) QA manager не нужен, так как внезапно QA становятся Team и теперь являются частью самоорганизающийся команды.
в) Вместо кучи Product manager’ов, маркетологов, sales’ов, которые постоянно совали нос в разработку пытаясь поменять порядок задач, теперь нужен один человек – Product Owner, который имеет право тасовать все задачи как ему вздумается (тут я немного преувеличил, но тем не менее, product managerская работа становится более видимой и их становится нужно меньше).
г) Программисты теперь не имеют право кивать на QA, что те чего-то не сделали. QA не имеел право кивать на программистов, что те чего-то не сделали.
д) Новый Scrum Master должен иметь БОЛЬШИЕ полномочия, для того чтобы расчищать путь для команды и водворять все стороны SCRUM’а. (в целом он конечно может бегать к мендежру каждый раз, когда нужно купить пишущих ручек, но это не так, чтобы слишком эффективно).
е) Лестница технического менеджмента тоже становится вроде как-бы и не слишком нужно, так как по сути они больше ни должны руководить.

Итого. Мы, что мы имеем? Мы протопталисья буквально всем по любимым мазолям, мы пытаемся отнять власть у /одних, выдать ее другим, вскрыть то, что кто-то пинает, а не работает и т.п. Как вы считаете, будут ли все вышеперечесленные очень рады нововведениям?

Нет…Нет… Противостояние не начнется в тот момент, когда будет предложена идея SCRUM’а. Оно не будет открытое. Просто, тот человек, который будет пытаться вводить Scrum (особенно если он не находится на верху иерархии) в какой-то момент обнаружит, что люди не спешат расставаться с их бывшими полномочиями и властью и не сильно спешат все делать по новому.

2) Второе, о чем почему-то редко говориться в Scrum, это о том как переводить проект с классического waterfall (или вообще отсутствия методологии) на Scrum. Опять же в большинстве книг рассказывается о том, что вот мол решили начать новый проект и попробовать Scrum. Извините… секундочку… То есть 80% рынка управления уже существующими проектами – нафиг из описания, а вот лучше мы опишем, как делать для остальных 20%, так как там поменьше зацепочек.

В чем собственно отличие старого проекта от нового проекта? Отличий несколько. Одно отличие – это существующий status quo (по большему счету то, что я описал в пункте 1 насчет власти), второе – это то, что уже есть код, заказчики, баги и т.п. И существует гигантская разница между тем, чтобы красиво и итерративно работать над проектом для которого нету заказчиков, нету багов и код которого новый и хороший.

Коротенький пример по этому поводу. Представим себе, что у вас есть продукт который активно пользуют, и в течении 3 недель (вашего спринта) вам приходит 3-4 бага от заказчиков которые надо пофиксить как можно быстрее. Модель Scrum’а такое не поддерживает. Содержание текущего Sprint’а не может меняться. И в этом смысле, в новом проекте, легко сказать всем вовлеченным – если есть баг, то мы его кладем в Backlog и пофиксим в следующем Sprint’е, в старом проекте где всегда фиксилось в течении 2-3 дней, явно менеджмент и customer support не оценит идею пофикса через 2 недели.

Собственно, это две самые крупные (по моему мнению) проблемы о которых не говорится в книгах. В следующей статье я капну чуть глубже.