Обзор Дилеммы Инноватора

Ссылки: озон, амазон.

Представьте такую ситуацию: вы работаете в компании с 5-10-20-50-100-летней историей, которая монополист (лидер) своего рынка. Вы и ваша компания все делаете "правильно" с точки зрения менеджмента: слушаете клиентов, знаете их от корки до корки и наперед их знаете, какая фича им нужна. Проводите маркетинговые исследования, реализуете только нужные и доходные фичи или продукты,  а те которые не нужны клиентам не делаете и не тратите на это бюджет.

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

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

Наверно менеджмент виноват или политическая ситуация, форс-мажоры  или какие еще-там-модные отмазки.

Кто же виноват и как это случилось ?

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

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

И вот инженеры, которые изобрели этот продукт отчаявшись, что в их детище компания не вкладывает деньги уходят из нее и открывают свои фирмы. И начинают искать тот рынок где были нужны лучший по критерию Х продукт (забавная аналогия из книжки про Джобса, нецарапающееся стекло для айфона никому нафиг не было нужно и было слишком дорогим для производства пока Джобс не начал делать тач-скрины, его умела производить ВСЕГО 1 фирма в мире).

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

А так как основной рынок то - вот он на виду то нишевой фирме, то хочется попасть и туда)

Постепенно нишевой продукт  развивается и по остальным критериям и ВНЕЗАПНО оказывается достаточного качества, чтобы конкурировать на основном рынке(за это время  конечно продукт на основном рынке стал ЕЩЕ лучше по своим основным критериям, но он уже ОПЕРЕЖАЕТ необходимый уровень качества на рынке).

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

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

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

Реальный пример:
Чтоб не быть голословным вот пример из индустрии жестких дисков(т.к. она "history moving fast"), каждые несколько-десяток лет в ней сменяются лидеры и рынок захватывают стартапы.

1.Инженеры Seagate в 1985 изобретают 3,5 дюймовый диск, в это время рынком доминирует 5,25 дюймовые(самым большим производителем которых и является Seagate).

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

3.Компания инвестирует в существующие технологии. Клиенты их за это любят и дают им много денег. 1)Технология существенно улучшается, 2)продажи растут, 3)профит!

4.Появляются новый компании(созданные бывших инженерами традиционных компаний).Методом проб и ошибок они находят новые рынки для своей продукции. Бывшие инженеры Seagate`a основали Corner Peripherals. Компания фокусируется на 3,5 дюймовый дисках, для них находиться рынок ноутбуков/портативных компьютеров.

5. На рынке появляются новые игроки. Производительность, объем и т.п. 3,5 дюймовых дисков постепенно позволяет им конкурировать с 5,25. 3.5- дюймовые диски начинают появляется в персоналках. Corner Peripherals вытесняет Seagate из рынка 3,5 дюймовых дисков для персоналок.

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


А происходит это не из-за недальновидности и глупости руководителей, а потому, что:


1) В хорошо управляемых компаниях на само деле КЛИЕНТЫ диктуют. куда будут вкладываться ресурсы. Лучшие инженеры, менеджеры и т.д. уходят в развитие основной технологии. Менеджеры даже не могут инвестировать в новые технологии потому, что это экономически не целесообразно и их проект просто зарубят.


2) Малые рынки не могут удовлетворить потребностей в росте больших компаний. Компании с 10 миллионами дохода, чтоб вырасти на 20%, надо заработать в следующем отчетном периоде - 2 миллиона, компании с 1000 миллионов дохода надо заработать  - 200. Зарождающиеся рынки такого не могут дать.


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


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


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

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


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

Отчет об посещении питерской SpmConf.

В прошедшую субботу (26 ноября) состоялась Software Project Management Conference. И прошла удачно) С кучей маститых и известных докладчиков, и парой-тройкой знакомых по твиттерам-блогам лиц)

Да и прошла для разнообразия не в Москве, а в Питере, что тоже по своему хорошо =) Своеобразный город, где еще люди, еще отмечающие пятницу, с утра субботы в баре угостят кофе (рано приехал к 6-7 к отелю и потому зашел в ближайшую по гугл-мапс кафе\забегаловку, где люди пили коньяк\пиво и играли в шахматы=)). А встречающаяся вечером пьющая алкоголь школота обсуждает Шопенгаура и поэзию 15 века =)

Вернусь к докладам и мои впечатлениям от конференции.

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

Начал с прослушивания доклада по результатам ежегодного исследования индустрии разработки ПО Валентина Макарова.
С одной стороны было интересно узнать, что вливания в ит внутри России прямо сопоставимы тренду цены на  нефть.
С другой докладчик, как-то честно рассказал, что растем мы не быстрее других стран BRIC`а в последние года даже чуть медленнее, что государству на Ит особо наплевать и вобще ситуация  в целом довольно грустная.
Думаю владельцам и работникам аутсорсеров и интерграторов данный доклад показался и покажется интересным)

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

Пошел послушать Максима Вишневского про отдельные вопросы анатомии менеджера, он рассказывал какие факапы и ошибки совершал в своей бурной пм-молодости, как переносил сроки проекта по 4 раза =) Переписывал проекты с нуля и все такое) Слушать развлекательно и забавно , но каждый в душе надеяться, что такие уж ошибки он то и не совершит) Хотя с другой стороны в конце доклада вышло, что совершить ошибки это хорошо - начинаешь понимать, что и где может пойти не так, приобретаешь опыт)

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

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

После Сергея краем уха послушал Вячеслава Нестерова (Генеральный Директор Санкт-Петербургского Центра Разаботки EMC), который рассказал, как их корпорация подходит к развитию своей инновационности, т.к. чувствует, что без инновационности - можно и отстать от конкурентов.
И поэтому докупает компании занимающиеся разработками продуктов на рубеже неизведанного (типа VmWare), и всячески поощряет коммуникацию и обмен знаниями среди своих подчиненных/
Круто, что большие корпорациии вобще задумываються об этом, с другой стороны доклад тоже достаточно специфичен и был бы интересен узкой категории, тех кто работает в похожих по размерам и глобальности компаниях)

Потому с его доклада я ушел слушать Михайла Ганчикова про развитие проекта в условиях нулей видимости)
Это когда есть сроки когда все должно быть готов и больше никаких знаний, что же придеться делать, т.е. требований на момент старта проекта не предполагается и точно известно, сто функционал из требований выкидывать не позволят =)
Вобще доклад довольно классно прошел, практически по идеальной схеме - объяснение проблемы - нагнетение обстановки - кульминация, прям как по книжке)

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

Потом пошел слушать Михайла Завилейского из DataArt`a: сначала был небольшой скептицизм из-за очень уж "боянных" тезисов в программке типа: почему заставлять коллег соревноваться плохо.

Датаарт похоже своеобразная компания, т.к. управляется эдакой массовой рассылкой на 28 человек(топ-менеджмента), без какого-то особого лидерства и руководства, как говорил сам Михайл он бы сам не поверил, что такое работает, если бы не видел это в живую.

Если во многих книгах про великие компании говориться, что чтобы стать великими вам надо иметь принципы\миссию\вижен, то они действуют от обратного - никаких особых принципов (кроме никто не должен выполнять бесполезной работы): все вольны иметь свои убеждениям, главное толерантно к друг-другу относиться и это работает).
Т.к. на рынке, где кандидатов на работу мало, компании с особой политикой и принципами вынуждены отсеивать не подходящих им людей, а Датаарт спокойной набирает их и растет, то их позиция - намного выгоднее.
Было рассказано про то, что кнут в общем-то не всегда работает, как задумано: если у человека есть возможность заплатить штраф например за опоздания и он не слишком большой, то вы фактически даете ему возможность купить индульгенцию, т.к. штраф он вроде как заплатил и журить после этого за опоздания его уже глупо)
Повторил довольно известную мысль, что в общем-то KPI ведут к оптимизации KPI и скорее всего приведут к "игре" - "мы играем по таким то правилам, мои KPI упадут, если я тебе помогу так что - пока" =)
В общем доклад навел на 10к-другой полезных мыслей =) Прослушал с удовольствием наверно  и засчитал бы его в топ-3 по всей конференции)

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

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

После волны не особо интересных докладов, пошел слушать Григория Печенкина  об "Культурных различиях в IT", в общем-то обзорно прошлись по разным полюсам типа доверия\паранои, команда\лидер и т.д. Как обзорный доклад может и хорош, но какую-то финальную  мысль, кроме того, что вот мол бывает так и сяк я не особо уловил. Тролль-команда в лице Михаила Заборова из Custis`а и еще пара человек, задавала каверзные вопросы, чем слегка оживила его дискуссией в конце и показала наличие московской тролль-культуры =)

Параллельно чуть послушал Ольгу Павлову из UsabilityLab, которая успешно развенчивала мифы о том, что Hr`ы важны и нужны(от коих на конференции было минимум 3 доклада, на которых они активно рассказывали почему не надо искать самому, а надо юзать их способности ) и нужны и рассказывала, как самим набирать программистов, менеджеров и прочих итшных личностей. Помню, что было вполне интересно и докладчица рассказывала в меру живу и интересно и даже приводила свою собственную систему hr-стайл GTD по найму.

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

один из этапов развития
матричной структуры

Что рано или поздно наличие матрицы и оптимизация ресурсов приведет к занятости 1,5 землекопа на проект, что крайне не эффективно и итогом этого развития, как не странно видятся готовые самоорганизующиеся кросс-функциональные команды (Внезапно, да ?)) =)

Было интересно послушать, как некоторый такой экскурс в историю, увидеть и понять как оно идет в типичном аутсорсере.
И тлеяла надежда узнать, что же там - за следующем level up`ом, но она не оправдалась)

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

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

Но гораздо интереснее были вторые участники в качестве "провинившегося сотрудника" выступил 1 из участников мастер-класса которые был настроен жестоко повоевать, перебивал пма, мастерски отмазывался, не хотел давать никаких обещаний, переносил разговоры на потом и т.д. Cотрудник-тролль-звезда в одном лице заставлял заливатсья хохотом весь зал так мастерски он уходил от ответственности и ответов на вопросы)
В итоге сам Дмитрий Башакин хотел показать, как надо доставлять обратную связь, но был им успешно затроллен в том числе =)
После по горячим следам разгорелась мини-дискуссия о том, что чтоб сотрудник мог вести себя ТАК, он либо должен быть незаменим либо сразу же уволен)

Предпоследним слушал доклад Дмитрия Безуглого про лестницу работы с потребностями потребителей, в какие-то идеи этого доклада я видел еще на ЛАФ`е (Летний Аналитический Фестиваль) и потому информация не была для меня совершенно новой.
Дмитрий разрабатывает свой фреймворк для создания продуктов для потребителей на основе идей Design Thinking собственного опыта и т.д. Цель которого создавать такой продукт, который может не только показаться интересным потребителю на неделю чтоб поиграться и уйти к конкуренту, но и чтобы покрыть его скрытые потребности типа ощущения себя себя избранным от работы с вещью, а не только от выполнения ею базовых полезных функций.
Довольно тяжело сформулировать всю концепцию словами, но будем надеяться видео с конференции появится в ближайшем будущем. Думаю доклад был бы интересен product менеджерам.

Вместо последних докладов пошел слушать стендовый доклад Стаса Фомина об Humanized Software Development, единственное о чем я жалею на этой конференции - что не пошел слушать его раньше, а успел лишь на последнюю треть, т.к. себя Стас не записывал =).

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

Стиль Стаса не передать словами, это эдакая веселые откровения наполненный глубокомысленной философией =) Надеюсь, что когда нить я все таки наткнусь на полную версию его доклада и посмотрю =)

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

Спасибо, что дочитали до конца, удачного вам дня. Увидимся на следующей #spmconf !

О разработке требований

Бывало ли у вас, что непонятно, что должна делать эта фича\таска\проект ?
Бывало ли, что при чтении кода или работе с программой становилось непонятно: это бага или фича ?
Возникала ли у вас хоть раз мысль: "что этой формулировкой тут хотели сказать, %№:%№ ?!" ?
Случалось ли хоть раз, что заказчик говорил вам: "это не то, что я вам пояснял !!!" ?

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

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

В общем думаю без преувеличения можно сказать, что все это видели, видят и еще долго будут видеть в будущем =)

вот как-то так и работаем =)

К чему это я: за 30-40 лет существования более-менее коммерческой части ИТ мы научились делать сложные, большие, высоконадежные, масштабируемые, качественные системы, но до сих пор не научились понимать, ЧТО и ЗАЧЕМ надо все таки реализовать.А процент успешных проектов - так и остался на уровне 30-40 %, с небольшим ростом около 5% за последние годы.
Новые технологии не спасают, т.к. проблема так и осталась в людях - мы просто плохо представляем, что же они хотят получить от нашей системы в итоге.

Эти мысли переодически меня волнуют  и потому, чтоб чуть лучше понимать почему такое случается, и что мы все делаем не так -  прочел "Разработку требований к программному обеспечению" Вигерса.

И МНЕ ОТКРЫЛОСЬ!

Шучу конечно)) Ничего сверхестественного не открылось, но где потенциально профакапить можно стал понимать лучше)

Вобще данная книжка по праву должна считаться "настольной книгой аналитика" и скорее всего ваш аналитик читал ее, если нет - то пусть прочтет.
У вас нет аналитика ?
Но кто-то же выполняет его роль ? Разаботчики\ПМ\ПО\юзабелист\маркетолог ? 
Никто ?
А ну тогда ясно почему вам приходиться переделывать, что-то по 5 раз прежде, чем заказчик это примет.
Кто-то эту роль выполняет - если он выполняет ее неявно и тяп-ляп - вам же хуже.

И в интересах компании, чтоб кто-бы ни брал на себя обязанности аналитика, чтоб он мог сказать почему и зачем так реализована КАЖДАЯ фича в вашем продукте.


Хотя бы вскользь прочитав первую главу, вы поймете: КТО, ЧТО и ПОЧЕМУ.

Анонимные пользователи

Кто.

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


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


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

ЧТО ?!

Что и почему.

Что такое требования ?
Как их разрабатывать и как ими управлять?
Зачем ими заниматься ?
Почему у хороших людей могут появляться плохие требования?
Как отличить хорошие требования от плохих?
Как заметить, что какие-то требования пропустили?
Как требования разрастаются и как происходит их "золочение" ?

Если вы не можете ответить на хотя бы 1 из вопросов или возникает смутное ощещение, что вы не понимаете о чем это - значит вам надо прочитать 1ю главу, как минимум =)

Как.

Вторая глава посвящена правильной разработке требований.

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

Иначе позвольте задать вам пару вопросов:
Что такое бизнес-требования, как они превращаются в образ и границы проекта?
Как найти и отобрать этого скрытого пользователя, который точно знает, что же ему нужно от вашего продукта?
Как выпытать из него нужные сведенья с максимальной пользой, эффективностью и удовольствием для обоих сторон(интим не предлагать)?
Как понять, что то что вы услышали, действительно, то что надо, а не получить "качели" ?
Что такое бизнес правила и с чем их едят ?
Почему документация не такое уж и зло, и как применить это зло во благо ?
Что такое атрибуты качества ПО и как их выявить ?
Зачем создаются прототипы ?
Как утверждать требования ?
Какие бывают проблемы при разработке требований ?
Вы таки создал требования - что делать дальше ?)
Кто убил Кеннеди ?

На эти и тысячи других увлекательных вопросов вы сможете узнать в нашем супер-пупер издании, которое так же излечивает гемморой, головную боль. И в добавок если вы позвоните прямо сейчас, то получите ... супер приз - АВТОМОБИЛЬ!!!.

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

Куда.

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

Ну а так, как к этому моменту вы поймете насколько у вас все плохо, то 4я глава расскажет вам как реализовывать этот самый процесс построения требований =)

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

Приятного чтения.

Обзор книги Эрика Берна "Лидер и группа. О структуре и динамике организаций и групп"

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

Если имя автора вам ничего не говорит, то можно загуглить "транзакционный анализ" и "родитель-ребенок-взрослый". Узнаете кое-что полезное =)

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

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

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

Группы можно классифицировать 10ками способов, а не просто "толпа коллег": по структурным, динамическим, рабочим, властным аспектами и т.д. "Коллеги за работой" и "толпа пьяных фанатов" - две группы но такие разные =)

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

Если по прохождению тренинга по командообразованию, мне было известно о двух типах руководителей "администратор" & "лидер", то теперь узнал что их 3:

• эффективный лидер - "доминирующий и влиятельный"
• ответственный лидер - "тот, кого призывают к ответу "
• психологический лидер - "первый после бога =)" - всемогущий, всезнающий и гениальный - в общем, как Стив Джобс для Эппла =).  

В общем почвы для размышлений можно понабрать на месяц-другой =)

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

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

Итого: первую часть можно и нужно почитать, вторую чтоб на практическом примере понять как же оно работает, и получить в голове пару озарений в стиле "ага, вот оно что!", а третью и четвертую - только если вам реально интересно и есть свободное время =)

Остаться в живых.

Прочитал очередную классику научной-фантастики современного менеджмента ит-проектов книгу Стива Макконела "Остаться в живых! Руководство для менеджеров программных продуктов".

Общее впечатление:

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

В рамках последних тенденций ажайла\лина и прочих "гибких" методологий довольно бюрократичная, не PmBOK конечно, но вполне себе увесистая. Что-то вроде PmBOK Light Edition =)

Некоторые из этих бюрократизмов несут довольно зрелое зерно, например интересной показалась идея именно выделенной "change control board", т.е. наличие выделенной команды, которая ответственна за внесение изменении и главное отслеживание их и ведение некоторого перечня, потому как уж очень часто встречается, что почему так сделано никто уже не помнит: "Sad, but true".

Суть книги в двух словах:
Лучше сразу делать процесс, и "наш процесс (tm)".

Как обычно

Как надо

В начале тяжелый процесс будет действительно отедать 30-40 % полезного времени. Но это лучше, чем альтернатива: чем дольше идет разработка, тем больше времени начинает уходить на "trashing" (т.е. пропадать впустую из-за бардака). И в процессе фиксинга бардака начинает появляться Процесс, который тоже отъедает полезное время.

И, ВНЕЗАПНО, оказывается, что проект на полезную работы отводиться ровно 0% времени.

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





Что было интересного: 

В книге приводиться чеклист (survival checklist): это возможность оценить по нескольким пунктам насколько высока вероятность успешного завершения проекта, каждый раз, как я считаю на моих работах получается, что лучше бы проект и не начинали или хотя бы 5-% на 50%, но все таки живут они как-то =). Хотя с другой стороны это хороший такой пример: TODO, что надо бы учесть и о чем не забыть. Можно иногда пробегать глазами, чтоб знать чего.

Хотя с другой стороны вопросы типа: "Does the project have detailed, written architecture and design documents?" как-то идет вразрез с теми же ажайл-принципами типа "don't overengineer ahead of time". Довольно неоднозначно это все, но взглянуть все таки стоит.

Пост с ссылкой на чеклист от Максима Дорофеева.

Еще показалась интересной техника defect seeding, как средство проверки качественности тестирования. Из названия ясно, что в разные места намеренно вставляются легко-исправляемые ошибки, и дабы определить сколько всего ошибок в софте.

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


Плюс интересной показалась еще одна идея: по окончанию проекта посмотреть и записать, что же было хорошо, а что же плохо -  эдакие МЕГА-ретроспективы. Мысль эта кажется, простой и очевидной, но к своему стыду нигде не применял сам и не видел, чтоб это применялось. Зачастую мы вынуждены ходить по тем же граблям раз за разом.

Итого:
Как первая книжка про software project management была-бы хороша, но если что-то уже читали более-менее серьезное, то максимум -  пробежать глазами и посмотреть, что же можно применить у себя + выписать чеклист, посчитать вероятность удачи, и посмотреть что же нужно исправить.

P.S. Книжку читал на языке оригинала поэтому цитаты на английском.

Майндмапы по командообразованию и работе с персоналом.

В рамках само-развития и подтягивания недостающих скиллзов переодически посещаю тренинги вот и в конце июня-начале июля сходил на тренинг Дмитрия Башакина "Работа с Персоналом в проекте".

Дабы уметь и знать, как же создать идеальную команду с нуля из того, что есть =)

Общий отзыв на тренинг:

Часть знаний была из разряда "Эврика!", т.е. отрефлексировал на себя в текущей позиции или понял, некоторый неодназначный опыт работы с коллегами\подчиненными, который у меня был.

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

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

Ключевые слова: модели Такмана, Бланшара, Левина,  Маслоу, Герцберга, теория ожиданий Врума, командные роли Белбина,  книги Ихцака Адизес.

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

Который и собираюсь выложить в открытый доступ - наверняка пригодиться не только мне =)

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

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

Если есть какие-то вопросы или непонятности - можно задать, тут либо на почту. И я разьясню или перерисую их, так чтоб вопросов стало меньше =)

Так что предложения по улучшению принимаются =)

Оригиналы майнд-мапов доступны тут: 

http://www.xmind.net/share/Techmind/

1 композитный, и 4 его составляющих, не пугайтесь вопросов в описании - это некорректная поддержка utf`a на сайте xmind`а =)

Сделаны в xmind`е, качаем, смотрим, урезаем до приличного вида(~ 1.3к элементов в итоговом, существенно тормозит в развернутом виде =)).


Они же в пнг:
(вобще картинки - просто ознакомиться, работать с исходными - легче и приятнее):

Полный:
http://dl.dropbox.com/u/31894017/teambuilding.png

Части:

http://dl.dropbox.com/u/31894017/leadervscontroller.png

http://dl.dropbox.com/u/31894017/teamvsgroup.png

http://dl.dropbox.com/u/31894017/workerprofile.png

http://dl.dropbox.com/u/31894017/forminganddeveloping.png

Если дропбокс будет ругаться на слишком частый доступ к картинкам, напишите мне по адресу bogunov (at) gmail (dot) com (и убедитесь, что я вам ответил, а то бывает письма попадают в спам =)), и я их выложу на какой-то общий хостинг или вышлю вам по почте.

Июньское чтиво: стреляем Серебрянные пулями и Поднимаем поезда из под откоса

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

Читал 2 книги : "Catastrophe Disentanglement: Getting Software Projects Back on Track", E. M. Bennatan

и "How To Run Successful Projects III: The Silver Bullet" Fergus O'Connell.

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

Чиним самолет в полете

Не секрет, что в отрасли разработки ПО затянувшиеся сроки, раздувшиеся бюджеты, периодические авралы и прочие увлекательные вещи не такие уж необычные вещи. "Shit happens" как говориться =)

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

В общем-то ее можно бы свести к одной фразе "Остановитесь и подумайте как так получилось, а потом составьте план исправления", а все остальное можно считать уже последствиями. 

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

Следующий шаг - "назначаем оценщика(Evaluator)", т.е. находим его, становимся сами или еще что, желательно со стороны чтоб мог придти и спокойна сказать - "да у вас тут батеньники - *#%№!" своим чистым и незамутненным взглядом, а то внутреннему человеку сложно это сказать, т.к. руководство по голове не погладит да и коллеги могут не понять такой формулировки.

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

И выделяем "минимально допустимые цели"(аналог MVP из agile(product-development) практик). Т.е. вместо создания комбайна делающего все и вся пытаемся создать инструмент делающий хоть что-то полезное. 

А теперь - проверяем а минимальные то цели достижимы ? Может быть идея создания искусственного интеллекта для тостера не была таким уж и выполнимым проектом ?

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

Если решили что цели то в принципе еще достижимы то пересобираем команду, это и дух моральный поднимет (они уже не те лузеры, что завалили проект изначально) и поможет поправить какие-то конфликты\проблемы в команде.

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

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

И наверное самое главное, что я почерпнул из этой книги - создать систему раннего предупреждения. Ведь проект не приходит в состояние катастрофы - "внезапно", как говорит Брукс: "How does a large software project get to be one year late? Answer:One day at a time!". 

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

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

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

Итого:

В общем книжка интересная подробным планом, и секциями "What can go wrong ?" на каждом этапе и рассмотрение основных проблем + способов их решения, + идея early warning system, которая часто применяется в средствах мониторинга за серваками, так же применима и к проектам. 

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

Серебрянная пуля

Следующая книга, бывшая в планах на июль - "Серебрянная Пуля"(How To Run Successful Projects III: The Silver Bullet) О`Коннела.

Такое наверно слегка наивное повествование в стиле, "вот те 10 шагов, которые выработались у меня и моих коллег со временем и делая их мы гарантируем ваш успех". 

Странно, что проекты до сих пор заваливают, хотя книга достаточно известная, да и думаю если б она гарантировала 100% успех, то ее знание бы стояла в требованиях во всех PM`ких вакансиях. Но тем неменее шаги и мысли в общем, то имеют некий базис и практическую пользу. 

Еще в книге есть такой забавный фактор типа PSI(Project Success Indicator), и чем ближе он к 100 тем лучше, книга написана в эдаком PMBOK-PM стиле: сначала мы все запланируем, а потом выполним план досконально и придем к успеху. И в итоге поделена на две части : планируем(первые 5 шагов) и выполняем(последние 5 шагов). И распределение шанса на успех 70% к 30%, т.е. сначала надо сильно-сильно все запланировать, иначе - можно проект и не начинать.

Хотя, как я уже упоминал шаги неглупые и достаточно полезные. 

И так по порядку:

1) Визуализируем цель.

Определяем кому, зачем и как надо получить готовый проект. Можно и нужно применить метод "The and-they-all-lived-happily-ever-after method", т.е. определить критерии достижимости цели и всякие такие полезные штуки. На самом деле действительно очень важная вещь, Макс Дорофеев в своем блоге приводил видео, в котором Сергей Мартыненко подробно обьяснял почему это действительно важно. Ну и visual management - это наше все и действительно удобно. 

2) Делаем список работ, которые должны быть сделаны.

И ведь не поспоришь же.

3) Должен быть только 1 лидер

Остаться должен только один! (с) Горец

Тоже, не вызывающий споров пункт.

4) Назначаем людей к работам

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

А вдруг окажется, что нет человека обладающего необходимыми навыками ? А учитывает ли другую работу, на которой может быть занят работник этот план ? Может его еще надо найти. Да и назначение типа: "написать модуль приема заказов  - работник 1" , "написать модуль отсыла заказов - работник 2" -  ни о чем не говорят.

5) Управляйте ожиданиями, имейте запас на ошибку, имейте позицию для отступления.

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

6) Используйте адекватный стиль лидерства.

Довольно подробный параграф о стиля лидерства, в ближайшее время выложу mind-map про команды и ситуационное лидерство в частности, так вот это о нем, немного другими словами но мысль тажа) Можно загуглить если вы первый раз слышите)

7) Знаем, что происходит на проекте.

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

8) Рассказываем людям, что происходит

Данный пункт относиться и к команде и к заказчикам, руководство и т.д. Опять же пятничные отчеты, общение с командой, ничего фантастически нового.

9) Повторяем шаги с 1 по 8 пока не шаг 10.

Просто и гениально =)

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

Собственно то, ради чего все и затевалось)

По автору все это: не сущей воды пустяки, но хотя бы накатанyый процесс.

Это было описание первой части =)

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

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

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

Итого: 

C одной стороны книжка вроде не бесполезная, и знание о стилях лидерства дадут например полезные знания, но с другой стороны с текущим agile-майнстримом, убеждения вроде можно все спланировать заранее и потом просто сделать вызывают не иллюзорные сомнения. Можно ознакомиться, чтоб знать как оно должно делаться в более-менее годном ватерфолле, с другой стороны есть пункт 9, которые хитро превращает весь процесс в итеративный =)

Управление проектами и жизнью: боевые действия и борьба

War, war never changes (c) Fallout

По совету товарища gaperton'a(Влад Балин) решил почитать "33 стратегии войны" Грина и Клаузевица "О Войне". 

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

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

1) делаются большим количеством людей с противоречивыми мнениями чего им надо

2) ведутся с целью профита, 

3) высокорисковее некуда 

4) зачастую с использованием последних технологий и новейших методологий

5) тысячи стейкхолдеров (целые государства)

6) много топ-менеджмента

7) да и вобще военное дело вполне себе такой двигатель процессов 

8) "любой другой эпитет применимый к софтверному проекту ..."

Трение

От Клацзевица помимо интересных мыслей, о том, что же такое война(хинт: крайне агрессивный способ достижения своих целей и просто одно из средств политики) и какое место она занимает в человеческой жизни\жизни государств и т.д. можно почерпнуть очень интересную мысль "трения".  

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

Если бы не "трение", войны могли бы идти по плану, по бумаге: 

полководец а: - ага, для нас лучшей стратегией было бы вот это: ******.

полководец б:- а мы бы могли отреагировать лучшим образом только, так ******. 

полководец а: - в итоге по расчетам мы выигрываем, что бы вы не сделали!

полководец б: - ок, шах и мат, забирайте вот эту территорию - вы победили.

Маловероятно не правда ли ?)

И это трение не возникает в немногих местах механизма которые взаимодействуют, оно возникает повсеместно, во всей системе, и потому оно так страшно и неконтролируемо.

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

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

Борьба и противостояние

Жизнь - есть постоянное сражение: борьба, конфликты, противостояние себе, миру, коллегам, конкурентам, "ктоещетам" - ведь не поспоришь ?)  

Что-то или кто-то мешает нам добиться своего, получить желаемое и вообще наслаждаться жизнью) 

Знай своего врага %username%! (надеюсь это не ты сам, но даже если так - все равно знать надо). 

И умей противостоять ему не как несмышленный и эмоциональный ребенок, а как логичный и проницательный стратег (от греческого - "Strategos" - полководец). 

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

Знать, против кого и как бороться - единственный способ выживания.

Вот с какой-то такой мысли и начинается замечательная книга "33 стратегии войны". 

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

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

Кроме того, концентрация смысла вынесены в отдельные абзацы - "ключи к военным действиям"

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

Борьба в обыденной жизни:

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

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

Какой-то человек может никак не реагировать на твои предложения, да и вобще не проявлять открытой враждебности(а в современном обществе - открытая враждебность чаще всего - неявное табу) или вобще быть вашим другом, чтобы уметь подойти поближе и знать, как побольнее ударить и тем не менее быть вашим врагом (хинт: enemy (враг)

происходит от латинского inimicus (не друг)). 

Знаешь своего врага - можешь объявить ему войну.

Живи и воюй настоящим! 

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

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

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

И продолжай в том же духе:

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

Распредели силы: контролируй хаос. 

На войне, как я уже говорил есть "трение" - элементы изменчивости, семена хаоса. И важно уметь быстро реагировать и уметь приспособиться к новой ситуации. Разбей своё войско на группы, способные самостоятельно действовать и принимать решения, дай людям миссию и позволь ее выложить. (Вот он lean в действии, а я наивно думал, что это все Тайота ! =) )

Обрати войну в крестовый поход. 

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

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

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

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

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

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

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

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

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

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

И так далее ... 

Итого

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

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

Да и даже если, вы считаете, что оно вам не надо и мир строится на согласии, конструктиве и win-win`е, то все равно прочитайте - "кто предупрежден - тот вооружен", не зря ведь придумали)

Peopleware(Человеческий фактор).

Прочитал недавно классику мировой фантастики менеджмента - сабж От Демарко и Листера)

Коротко расскажу, чтоб было нового и интересног из того, что запомнилось:

Интересное:

1) Книга  наполнена яркими тезисами, которые так и не терпится выписать и наклеить на стену (читал в оригинале потому и тезисы на англиском):

• The major problems of our work are not so much technological as sociological in nature.
• We Haven't Got Time to Think About This Job, Only to Do It
• People under time pressure don't work better; 
• they Just work faster
• Quality, far beyond that required by the end user, 
• is a means to higher productivity.

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

2) Том Демарко и Листер обыденно говорят, что ничего такого волшебного не случиться и никакая мега-нова методология\технология и т.д. не помогут выполнять проекты на 100 % лучше, попутно обсуждая, что "Программы Улучшения Процессов"(на примере CMM) ни разу не помогают , т.к. ведут к эффективному производству того, что вы итак умели делать. Что ведет к снижению рисков, но обратным эффектом будет снижение создаваемой ценности и доходности бизнеса. Довольно спорный момент, т.к. отсутствие таких программ ни разу не дает гарантий улучшений чего-либо в ближайшей перспективе и насколько мне известно ВСЕ программы улучшения процессов нацелены именно на долгосрочное развитие.

3) Целая ЧАСТЬ(2-ая) посвящена вопросам обстановки офиса и обустройства пространства дабы работать было комфортно:

- Удивительно, что ДО СИХ ПОР (проблема с местом\посторонним шумом\постоянными отвлечениями актуальна на всех работах, где мне приходилось работать) такое положение дел еще действует.

- Об этом не высказался только ленивый): например Саша Орлов на PmDays еще в далеком 2008м, где-то еще слышал историю(ссылку не найду) от Славы Панкратова про невозмутимого тестировщика, которого отвлекали по 50 раз на дню.

- Авторы предлагают метрику E-Factor эффективности офисного пространства: количество ЦЕЛЫХ(совсем без отвлечений на посторонние звуки) часов деленное на количество часов проведенное на работе, которое удалось провести без единого прерывания. 

Кто-нибудь готов сказать что он хотя бы дотягивает до 0.5 не говоря уже от 0.8-0.9 ?).

4) Хотя авторы и против всяких монструозных программ улучшений процесса, но меняться всеравно надо иначе отстанешь, станешь древним диназавром ну и т.д.

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

Соответственно надо уметь выбрать тех, кто станет твоими союзниками в изменениях:

из 3х групп: 

1) Те, кто слепо последуют за новой идеей

2) Те, кто будут задавать вопрос: что в этом для меня ?

3) Те, кто категорически будут отрицать ее.

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

При прочтении вспомнился замечательный доклад на ту же тему от Хенирка Кенинберга Everyone likes change, but nobody likes to be changed (Henrik Kniberg, AgileDays-2011)

Новое:
1) Узнал как же называется подход, когда из работника пытаются выжать максимум рабочих часов, оказывается это называется  -  испанская теория управления. Ответвляется она от испанской теории ценности - ценность конечна и ее надо уметь отбирать(а ля Конкистадоры), знаю пару человек которые могла бы по ней книги писать)

2) Внезапно откровением, оказалась глава  в которой Авторы рассказывают, что закон Паркинсона не совсем работает, и наиболее продуктивными оказываются те команды у которых нет дед-лайнов и оценок размера работ (всетаки оценка работ - waste, в самом тру-lean смысле).
Хотя с другой стороны может быть они уже были настолько круты и продуктивны, что оценка работ действительно не была нужна.

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

3.5) Опять же понравилась история про(внимание барабанная дробь) ЧОРНУЮ КОМАНДУ ТЕСТИРОВЩИКОВ! Суть которой в том, что компания сумела создать такую команду, которая выработала свою философию "деструктивного" тестирования и находила в этом свой fun & lulz, и дух и философия этой команды даже пережила уход ВСЕХ изначальных членов этой команды.

4) Вроде бы очевидная вещь и баян, но все же этому разделу посвящена опять же целая часть:

"IT'S SUPPOSED TO BE FUN TO WORK HERE" - компания должна быть такой, чтоб работать было интересно и не скучно. Дюди должны чувствовать, что компания вкладывает в них и заботится о них и подразумевается, что люди останутся в ней надолго. Соответственно если компания хороша - у нее очень маленький отток людей (Гм, это наверно классный критерий оценки\поиска работы !).

Итого:
Количество полезных идей\на символ (думаю отличная метрика для книги) в книжке зашкаливает, посему - must read (но вы ведь это знали и без меня, так ведь ?).

Обзор Искусства Управления IT-проектами (Making Things Happen) Скотта Беркуна.

Во время прочтения этой книги выработал для себя новый критерий качества чтива: через 5-10 минут продолжения\начала чтения судорожно ищешь карандашь, чтоб подчеркнуть полезную и интересную мысль, а карандашь превращается в закладку, чтобы потом долго его не искать =)

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

И да книжка не про ажайл\лин, а просто про управление проектами =)

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

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

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

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


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

Цели и концепция проекта:

1)Наиболее распостранненные просчеты в определении конечной цели проекта:
 - мы будем делать то же , что и в прошлый раз
 - мы будем делать, то чем принебрегли в прошлый раз
 - мы будем делать то же самое, что и наш конкурент
 - мы будем делать, то что отвечает модным тенденциям (сделаем веб-два(три)-нольно и стартап !)
 - если мы сделаем этот продукт, он обязательно найдет своего покупателя

2) При формулировке цели можно воспользоваться таким приемом - отнеситесь к ней максимально придирчиво и задатьяс вопросом, не провалиться проект, если его цель будет достигнута в точном соответствии с его формулировкой. Затем нужно подумать, а нельзя ли более точно сформулироваться цель, нет ли какой-нибудь дополнительной, уточняющей информации.

3) Если вы не в состоянии найти какое-нибудть визуальное представленеи того, что изменится в этом мире под влиянием проекта, стоит задуматься не направлен ли этот проект на создание бесполезных вещей. или достаточно ли он понятен, чтобы быть успешно притворенным в жизнь.
3.1) Что концепция всегда была на видном месте, несколько ключевых целей проекта должны быть оформлены в виде плакатов, расположенных в наиболее людных местах (визуальный менеджмент в стиле Лин !)

Выбор Идеи:
 - Какую именно проблему мы пытаемся решить ? (При возникновении споров о том, что и как делать.)

Информированность: 
 - По возможности старайтесь избегать информации из 2-х, 3-х и 4-х рук. Во время разговора часто вскрываются детали и нюансы по тем или иным причинам не попавшие в отчет или презентацию.
 - Люди ценятся выше информации. Человек пишущий отчет, изучил 1000 разных веещй и узнал массу полезной информации, которую невозможно втиснуть целиком в этот отчет, но который он с радоситью поделиться с теми, кто проявит достаточное любопытство.
 - Хорошие решения могут давать плохие результыта.

Общение: 
 - Базовая модель общения:
- Передача
- Получение
- Усвоение
- Согласие
- Превращение в полезые действия
Не факт, что ваше сообщение не остановилось на уровне передачи или получения ! То, что вы что-то сказали\написали ничего не говорит о его усвоении, или о том. что с вашим сообщением согласны.

Почему люди раздражаются: 
 - Не считайте меня идиотом.
 - Доверяйте мне.
 - Не тратьте мое время попусту.
 - Не распоряжайтесь мной без должного уважения.
 - Не заставляйте меня слушать или читать всякие глупости.

Формула хорошего процесса:
Полная стоимость процесса:

• время на выработку замысла процесса(DT),
• время на его освоение командой(LT)
• фактическое время выполнения работы при применении процесса, помноженное на частоту его применения (ATxN)

= DT + LT + (AT x N)
Суммарная выгода процесса:

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

 =   (FC x FP) x T
А ценность процесса равна:  ((FC x FP) x T) - (DT + LT + (AT x N))

Итого:
Не зря она занимает свое место а бест-селлерах О`рейли и для всех кто интересуется разработкой ПО должна находитсья в разделе must have & must read.
Думаю перечитаю ее еще не раз через месяц-другой, чтобы освежить в памяти и найти какие-то новые моменты .