greesha

Прикрутил первую мобильную версию к сайту it-map: http://m.it-map.ru

Проверял на единственном мобильном устройстве, имеющемся под рукой: отобрал у дочки телефон. Ну и на разных эмуляторах попробовал, конечно: андроидном, айфонном, opera mini.

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

(Кстати, выражение «черкнуть пару строк» явно устарело, причём дважды: сначала в результате всеобщей компьютеризации, а теперь ещё и благодаря тотальной мобилизации. Чем его можно заменить?)

Прислали ссылку на новую книгу издательства «Манн, Иванов и Фербер»: Вадим Богданов. Управление проектами.

«Почему мы издали эту книгу?» — как бы спрашивают сами себя издатели. И тут же как бы сами себе отвечают: «Потому что принципы проектной работы, изложенные здесь, универсальны.»

Ну что же, заглянем внутрь. Благо отдельные главы выложены для ознакомления.

Первым делом я полез в главу «Система мотивации». Прочитал два раза. Потому что с первого раза не поверил. После второго раза убедился: автору известны только два способа мотивации. А именно: 1) премии и 2) штрафы.

Ну ладно, допустим, знание принципов мотивации — не самая сильная сторона консультанта по впариванию MS Project по внедрению корпоративных систем управления. Почитаем лучше главу об эффективном управлении проектами.

От следующей фразы у меня на глаза навернулись слёзы.

Если вам удастся стандартизировать процессы управления проектами, то для управления ими вам потребуются не руководители проектов, а администраторы. При строгой стандартизации нет управления как такового: планирование проекта не требуется (оно заменено выбором одного из шаблонных вариантов), необходим только контроль за ходом проекта и эскалация возникающих проблем на уровень руководителя, контролирующего ход выполнения портфеля проектов.

Это же голубая мечта директоров-социопатов, играющих в «серьёзный бизнес» на бумажках с описанием оргструктуры, но боящихся выглянуть в окно, за которым раскинулся хаос реального мира!

И пусть автор в этой цитате имеет в виду только один из трёх типов проектов по его авторской классификации: тип «Процедура» (оставшиеся два типа называются «Седина» и «Мозги»). Этот тип в его понимании главный: по мнению автора, внедрение КСУП (корпоративной, стало быть, системы управления проектами — сокращаем помаленьку) позволит довести долю таких проектов в организации до 90%.

В общем, моё личное оценочное суждение такое: книгу в печку, аффтара крабом на галеры, издательству — общественное порицание. Кажется, их планка качества очень сильно упала.

Печально то, что книга таки найдёт своего читателя, тех самых собственников и топ-менеджеров, решивших автоматизировать управление проектами в своем бизнесе. Впрочем, по-настоящему печалиться имеет смысл только в том случае, если попадёшь в железные шестерёнки этой самой КСУП. Если с вами такое случилось, на всякий случай информирую: крепостное право у нас отменили 150 лет назад.

Корпоративная культура — это акционерное предприятие, в котором у генерального директора 51% акций. Затевать изменения в культуре, не заручившись его поддержкой, — значит с самого начала обречь их на провал.

b_l_v

Скачать книгу "Гибкие методологии разработки" (более 400 скачиваний)

• Гибкие методологии разработки
• Предисловие
• Agile-методологии
• Scrum – гибкий управленческий фреймворк
• Масштабирование Agile
• Управление командой
• Управление контрактами
• Управление продуктом
• Управление рисками
• Инженерные практики
• Контроль и обеспечение качества
• Анализ требований
• Бережливое производство
• Как внедрить Agile за 14 недель
• Гибкие компании-аутсорсеры
• Консалтинг-компании и независимые тренеры
• Предметный указатель
• Список литературы

• Разработчики
• Ведущие разработчики и архитекторы
• Скрам-мастера
• Руководители проектов
• Владельцы продуктов
• Руководители отделов
• Аналитики
• Тестировщики
• Верстальщики
• Дизайнеры и специалисты по интерфейсу

И вот я уже оформлял свои двадцать билетов. Красивым почерком, так как от этого зависело все, я указывал место и время встречи. Внизу стояла подпись «Боря».

Результат превзошел все ожидания. В воскресенье у памятника Ленину стояли девушки с нашими картоночками в руках.

От мороза бомбы были покрыты инеем. Густой слой масла, покрывавший обруч и бугель подвесной системы превратился в камень. Его не брал даже нож.
…
Прошедший войну бесстрашный летчик увидел костер, где лежали две бомбы. Четыре другие рядом. Он хотел что-то сказать, но голоса не было. Ноги стали ватными, и он замер, как памятник, с поднятой рукой.

В книге «БесЦельная жизнь» предлагается сделать такое упражнение.

Составьте список из 101 цели, которых вы хотите добиться в ближайшие десять лет. Отведите душу, рассмотрите все возможности. Отдайтесь детскому энтузиазму — не ограничивайте себя ничем. Будьте точны и придавайте списку личностный характер, начиная каждое предложение со слова «Я…». Например: «Я проведу полтора месяца в отпуске в Европе» или «Я буду откладывать 10% от моего дохода каждый месяц».

Решил попробовать. Заранее сел в электричку, устроился поудобнее, достал блокнот и начал писать.

Первые пять целей, расталкивая друг друга, сами рвались из головы на бумагу.

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

Двадцатая цель была записана уже где-то в районе платформы Северянин.

Дальше начались трудности. Каждая новая запись требовала всё большего и большего напряжения мысли. К платформе Лось накопилось около трёх десятков. На тридцатую навёл проходящий мимо мужичок, наигрывающий что-то на баяне. Записал: «научиться виртуозно играть на аккордеоне» (была у меня в детстве такая мечта).

За оставшиеся две остановки натужно выдавил из себя ещё две цели. Очень уж надуманные, на мой взгляд.

И всё. Тайнинская, мне выходить. В блокноте 32 записи, и больше я не смог придумать ни одной.

И вот теперь сижу и думаю. Это потому, что у меня такое скудное воображение? Или мне так мало в жизни надо? Или, наоборот, я так хорошо сфокусирован, что не могу разбить свои желания на 101 часть?

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

Прислали ссылку на отличную статью о том, почему не работают традиционные советы по тайм-менеджменту.

Статья пришлась очень вовремя. Я как раз предпринимаю очередную попытку расписать цели, систематизировать задачи и завести календарик-пинарик. Рекорд жизни моего пинарика — девять месяцев. К концу этого срока я заполнял его с труднопреодолимым отвращением.

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

Очевидно, что система у меня не работает. Варианта, вроде бы, два: работать над собой или менять систему. Но я с годами всё больше и больше убеждаюсь, что изменить человека (особенно себя) — практически невыполнимая задача.

А тут подвернулась новая система:

• Без пошагового плана;
• Без приоритетных дел, которые нужно сделать в первую очередь;
• Без сроков и чётких дат;
• И, наконец, система без целей!

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

Оказывается, коллега, сидящий рядом со мной, тоже был добровольцем-наблюдателем на выборах (официально — от Яблока). Избирательный участок 190 в Хамовниках.

Его рассказ: после закрытия участка председатель комиссии куда-то исчезла, а комиссия пошла пьянствовать. Через три с половиной часа вернулась председатель, а за ней следом пришёл какой-то мужик с намерением принять участие в подсчёте (возможно, это был член комиссии). На вопрос наблюдательницы от КПРФ «кто вы такой?» ответил грубостью. Коллега попытался снять видео этой беседы, после чего председатель комисии мгновенно предложила удалить всех наблюдателей «за драку на избирательном участке». В том числе тех, кто мирно просидел на скамеечке весь день.

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

Официальные результаты по этому УИК:
ЕР — 86.22%,
КПРФ — 3.87%,
Яблоко — 2.78%,
СР — 2.31%,
ЛДПР — 0.81%

Официально на участке проголосовало 1441 человек, а по подсчётам наблюдателей — примерно 700.

Чуть не поругался только что с женой.

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

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

Немного успокоившись, задал себе вопрос: из-за чего же я так разозлился? Вывел меня из себя, конечно же, «утверждённый образец». Образец иллюстрирует типичную проблему подобных регламентов: составитель стандарта пребывает в уверенности, что достаточно указать в плане обязательное достижение каких-то результатов, а все необходимые для этого процессы волшебным образом возникнут сами собой.

Вот, например, учебная программа должна обеспечивать «формирование личностных ценностно-смысловых ориентиров и установок, личностных, регулятивных, познавательных, коммуникативных универсальных учебных действий.» Должна? Должна. Так что, дорогие учителя-химики, будьте добры, составьте табличку и вписывайте: какие ценностно-смысловые ориентиры и установки вы будете задавать и какие «регулятивные учебные действия» формировать. И, будьте любезны, не смешивайте личностные навыки с коммуникационными — это разные графы таблицы! Это вам не пробирки пачкать, тут думать надо.

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

Кажется, я опять начинаю скрипеть зубами.

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

Хвала прогрессу, теперь есть интернет и добрые учителя, выкладывющие в него свои планы. Это, конечно, здорово облегчило ежегодные мучения их коллег, выполняющих обязательное поурочное планирование. Но тут нельзя обойтись без здорового цинизма. Нужно просто скачать чужой текст, поменять в нём формальные признаки (фамилию, год), распечатать и сразу сдать, ни в коем случае не вчитываясь в текст. Попытка внести элемент здравого смысла в этот процесс может привести к слезам и семейным сценам.

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

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

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

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

Правда, это ведь совсем несложно. Даже если поначалу вы испытываете некоторое неудобство, я уверен, что буквально через несколько страниц вы привыкнете. Вам, вероятно, даже не придётся останавливаться после каждого абзаца — вы автоматически станете подсчитывать слова прямо во время чтения.

Очень важный момент: не относитесь к этому упражнению, как к «мысленному эксперименту». Будьте честны сами с собой: возьмите книгу и сделайте.

Что вы говорите? Не нравится читать? Перестали получать удовольствие от чтения? Потеряли сюжетную линию из-за того, что голова занята постоянным подсчётом? Странно… Это ведь так естественно и даже интересно — иметь собственную метрику скорости чтения! Вы можете использовать её, например, для оценки количества книг, которые вы сможете прочитать до конца года. Или для оценки эффективности программы скорочтения (которой вы непременно захотите воспользоваться, получив наконец-то адекватную оценку своих возможностей). В конце концов, получение удовольствия от чтения — это ваш сознательный выбор, то есть управление собственным досугом. А как вы можете управлять тем, что не можете измерить?

А сюжет… Да и чёрт с ним, с сюжетом. Давайте будем честными до конца: все эти сюжеты неотличимы друг от друга. И вообще, что это за странная мысль — получать удовольствие от чтения?

Вы знаете, для чего предназначено сочетание клавиш Win+L? Вы используете его, когда идёте пить кофе?

У вас в офисе есть шредер? Вы часто им пользуетесь?

Вам когда-нибудь приходилось согласовывать своё выступление на конференции с PR-отделом или службой безопасности вашей компании?

Если вы ответили «Да» на большинство вопросов, то не заражена ли ваша компания корпоративной паранойей?

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

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

Безопасность — это такая скользкая тема, в которой мало кто готов брать на себя ответственность. В армии знают: самое страшное взыскание — «за нарушение режима секретности». Страшно оно тем, что практически неснимаемо. Любой другой проступок можно со временем загладить и искупить, но если в личном деле есть запись с такой формулировкой — на карьере офицера можно ставить крест.

Может быть, компания в прошлом была государственной организацией, работавшей на оборонку, и унаследовала методы защиты из своего героического прошлого. Или в штате компании есть бывший сотрудник спецслужб или приснопамятного первого отдела, отвечающий теперь за информационную безопасность. Такие люди обычно руководствуются принципами «что не разрешено, то запрещено» и «лучше перебдеть, чем недобдеть». Если дать им власть устанавливать правила, то эти принципы быстро просачиваются в культуру компании.

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

Вы хотите повесить на стену доску задач, но вам нельзя писать на ней имена клиентов (а вдруг один из них придёт к вам в офис и увидит название своих конкурентов?)

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

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

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

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

Что открытие исходного кода внезапно привлекает на сторону компании армию добровольных помощников, готовых использовать, тестировать и рекомендовать другим её продукты просто «за идею».

Что снятие грифа со спецификаций вдруг превращает их в отраслевые стандарты, и конкуренты оказываются вынуждены подгонять под них свои протоколы.

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

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

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

В этом измерении мои предпочтения однозначны: я — за максимальную открытость. Компания моей мечты — это открытая компания, не боящаяся рассказывать правду о себе, активно делящаяся положительным опытом и знаниями и не превращающая информационную безопасность в корпоративную паранойю.

Другие статьи цикла

Проделайте такой эксперимент. Можно мысленно.

Возьмите последний крайний релиз своего продукта и поменяйте в нём одну цифру в версии. Любую. Больше ничего не меняйте.

Теперь прогоните этот релиз через все принятые у вас в компании круги ада процедуры и регламенты. (У вас CMMI 5 lvl или ISO over 90000? Сами виноваты. :-P)

Учтите это изменение в требованиях к продукту или в запросах на изменение. (Если есть где учитывать.)

Проведите ревью кода. (Эти кодеры такие кодеры!)

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

Прогоните автоматические модульные тесты. (Если они у вас есть, конечно.)

Выполните все положенные тесты чёрного ящика. (Кто гарантирует, что смена цифры ничего не сломала?)

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

Внесите изменения в документацию. (Когда выполняете поиск по тексту, не забывайте про картинки — ваш К. О.)

Создайте инсталляционный пакет и опубликуйте его как заведено.

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

Всё это делайте по-взрослому, с использованием всех багтрекеров, СУТов, систем отслеживания заявок, эм-эс-проджектов и прочей лабуды автоматизации.

Да, чуть не забыл: в процессе тщательно учитывайте трудозатраты. (Бросая в воду камушки, смотри на круги, ими образуемые, иначе такое бросание будет пустою забавою — Козьма Прутков.)

Что мы получаем на выходе? На выходе, товарищи, мы получаем накладные расходы на доработки.

Что нам теперь с ними делать? А что хотите, то и делайте.

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

Или придумайте себе правильную пропорцию между полезными и накладными трудозатратами и всегда её соблюдайте. (Например, 40 к 60, как учил нас Д. И. Менделеев.)

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

Или с недоумением пожмите плечами. (Регламенты, тесты какие-то… голова пухнет! Взять всё да и выложить на боевой сервер.)

В общем, развлекайтесь, как умеете.

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

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

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

Ресурсы или люди

Меня всегда немного коробит, когда тимлид говорит мне что-то вроде «этот ресурс освободится только в четверг». При этом «ресурс» сидит у него за спиной. Какой ресурс? У него имя есть!

Отношение к людям как к «ресурсам» прочно закрепилось в умах многих менеджеров. Немалую роль в этом сыграл популярный MS Project, который почему-то все называют «инструментом управления проектами», хотя это всего лишь инструмент планирования. Правда, в свежей версии 2010 MS Project наконец-то начал понемногу поворачиваться к людям лицом: в нём появилось новое представление «Планировщик командной работы» — звучит (и выглядит) уже намного лучше, чем «выравниватель ресурсов».

«Человеческий ресурс» — это абстракция, изобретённая экономистами в попытке отделить человеческий труд от его носителей — людей. Главная характеристика «человеческого ресурса», производительность, позволяет выражать объём выполняемой работы в «трудозатратах», которые, в свою очередь, пересчитываются в деньги. Чаще всего производительность объявляется константой, что превращает трудозатраты в линейную функцию времени. (А экономисты, как известно, признают только линейные функции. ;)

«Наука управления проектами» с готовностью подхватила эту модель, но перевернула при этом формулу: раз трудозатраты — это линейная функция времени, значит, теперь мы можем прогнозировать время выполнения работы! Нужно только «точно» оценить трудозатраты и поделить их на производительность — только и всего.

При таком подходе модель «человеческого ресурса» окончательно вырождается в один-единственный коэффициент — производительность. А это тянет за собой важное допущение о взаимозаменяемости людей (мы ведь просто меняем коэффициент), которое всегда нужно принимать с большой осторожностью.

Модель, в которой создаваемая людьми ценность измеряется трудозатратами, наверное, имеет право на жизнь. Но, как это нередко случается с абстрактными моделями, при её использовании постоянно забывают о границах применимости. Модель «человеческого ресурса» может использоваться для прогнозирования в случаях, когда:

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

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

Конечно, я не предлагаю предать анафеме все существующие методы управления проектами только за то, что они называют людей ресурсами. Модель управления на основе трудозатрат изобретена давно, и довольно успешно используется во многих областях. Но её коварство в том, что отношение к людям как к коэффициентам уравнения незаметно выползает за пределы модели и становится характерной чертой корпоративной культуры. И тогда появляются на свет, например, такие «управленческие решения»:

- Использование этого ресурса в данном проекте нецелесообразно. («Ресурс» осознал, что он тянет на себе весь проект и осмелился потребовать повышения зарплаты. Стоит ли говорить, что замена его другим ресурсом привела к потере заказчика.)

- Самая трудоёмкая фаза проекта завершена, и нам больше не нужно такое количество ресурсов. (Всем спасибо, все свободны, компания в ваших услугах больше не нуждается. При этом почему-то вместе с «освободившимися ресурсами» ушли и те, которые освобождать не планировалось.)

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

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

Другие статьи цикла

Не люди должны быть втиснуты в чисто теоретические организационные формы, а организация должна строиться вокруг тех людей, которые есть. Фредерик Брукс

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

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

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

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

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

В лучших командах лидерство переходит от одного человека к другому в зависимости от области специализации. Никто не становится лидером навсегда, потому что такой человек мгновенно перестаёт быть равным, что обязательно нарушает взаимодействие в команде. Том Демарко и Тимоти Листер

Компания моей мечты, наверное, будет состоять из самоорганизующихся команд. Конечно, состав команд будет меняться во времени. Что же касается должностей, то вместо жёсткой организационной структуры и «тарифной сетки» для каждого человека компания будет создавать должность, соответствующую его реальной ценности для компании. Эти должности могут называться как угодно. Они вряд ли будут соответствовать какому-то классификатору должностей или «табели о рангах».

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

В последнее время всё чаще поднимается вопрос об отличиях разных Agile-подходов к разработке (свят-свят-свят, чуть было не вырвалось «методологий» ;). Об этом можно почитать, например, здесь или здесь. И ещё много где, как подсказывает нам Гугль. А вездесущий Асхат Уразбаев уже проводит специальный тренинг, разъясняя, что Lean — это как бы не совсем Agile, но что Lean делает Agile лучше.

Попробую и я внести свои дилетантские пять копеек.

В моём представлении XP — это такой «идеальный» Agile. Это практически полный набор Agile-практик (сначала их было 12, а теперь, я слышал, это число удвоилось, но эту книгу я ещё не читал). Используйте все практики XP — и у вас наступит полный Agile, процветание и благоденствие.

Одна беда: перечислив и описав все эти практики, отцы экстремального программирования не объяснили толком, как со всей этой фигнёй взлететь всё это добро внедрять. Наверное, поэтому среди моих знакомых нет ни одного человека, реально работавшего когда-либо в проекте, разрабатываемом по XP. Зато есть парочка бывших теоретиков-энтузиастов использования XP, мечты которых разбились о неприступные скалы корпоративной культуры и полное непонимание со стороны коллег. Да что греха таить, я и сам потерпел неудачу при попытке внедрения парного программирования — мои коллеги, однажды попробовав эту практику, категорически отказались продолжать эксперимент (я их, помнится, после этого ещё долго пугал: не закончишь задачу к сроку — будешь весь день работать со мной в паре).

Шум по поводу XP постепенно стих. Хотя полки книжных магазинов тихо заполнялись книгами, заголовки которых странным образом совпадали с названиями практик XP.

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

В отличие от XP, Scrum сразу начал своё победное шествие по планете. Некоторые злые языки утверждают, что дело тут в его неуёмном пиаре хорошо проработанной маркетинговой модели, но лично я думаю, что причина в другом: применение Scrum действительно позволяет быстро решить наиболее злободневные в отрасли разработки ПО проблемы.

Scrum сразу концентрируется на наиболее типичных слабых местах процесса разработки, а именно:
— общение с заказчиком;
— обмен информацией и координация действий внутри команды.

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

Благодаря простоте и немногочисленности правил и инструментов Scrum, их можно внедрять сразу. Вот так просто: взять и начать со следующего понедельника. Сначала просто и тупо следовать правилам, и после пары-тройки итераций вам явится дух Agile. (Хотя для надёжности, может быть, и стоит позвать Scrum-шамана.)

Как соотносится Scrum с XP? Да прекрасно соотносится. Разве Scrum запрещает вам использовать парное программирование? Или непрерывную интеграцию? Или test-driven development? Конечно, не запрещает. Scrum — это отличный первый шаг в мир Agile, и если он окажется удачным, то вам наверняка захочется сделать следующие шаги.

Но в каком направлении их делать? И вот здесь нам на помощь приходит Lean. Lean — это не методология и не свод правил. Это, скорее, философия. Или, как минимум, набор принципов. Корневую идею Lean, как мне кажется, выражает цитата из книги Мери и Тома Поппендик «Бережливое производство программного обеспечения»:

Именно постоянное совершенствование процесса покажет направление для следующих шагов.

Сами принципы Lean, а также советы по их реализации применительно к разработке ПО, содержатся в этой же книге, и пересказывать их я не буду. Кстати, не советую пытаться составить представление о Lean только на основании краткого перечисления этих принципов (таких «шпаргалок» уже немало в интернетах). Лучше возьмите эту книгу и прочитайте. Там есть над чем подумать.

Суммируя всё сказанное, идеальная «дорожная карта Agile» мне сейчас представляется так: от Scrum через Lean к XP. Идеальная не смысле «самая лучшая», а в смысле чистой идеи, которой требуется подтверждение практикой.

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

На практике самыми сильными оказываются такие компании, которые объединяют таланты всех своих членов, поощряя свободный обмен идеями. Джо Мараско
 

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

Свершилось. Я всё-таки уволился.

Я уже забыл это ощущение: эйфория свободы, смешанная с чувством тревоги. Когда тебе кажется, что все пути перед тобой открыты. И в то же время страшно, непонятно: как оно будет дальше?
 

Компания, которая предложила мне место, вдруг передумала. То есть, конечно, компании думать и предлагать не могут, это делают люди. Одни люди в компании меня пригласили, а другие за них передумали. Но я им всё равно благодарен: не имея их предложения в кармане, я бы, наверное, в очередной раз не решился сказать «Я ухожу». Это было труднее всего – заявить о своём уходе после восьми с половиной лет на одном месте. Даже если давно собирался это сделать.
 

cartmendum'а

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

Подавляющее большинство дефектов — это в действительности проблема менеджмента.

Где же всё-таки висит этот плакат? Вроде бы есть люди, которые видели его своими глазами. Поделитесь, коллеги! Может, мы зря смеёмся над «тупым демотиватором»?