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

А success story потому что Сингапур первый в списке лучших стран для бизнеса.

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

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

PS нет, сама книга не про то что нужно во всем лениться, это лишь часть идеи, название не совсем корректное

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

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

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

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

Если интересно то об этом можно прочитать в книге «A Taste of Irrationality» Дэна Ариэли, она бесплатная, для iBooks и Kindle. Ну и, на самом деле, это лишь пара статей из других книг того же автора.

Он выделил 4 роли: Producer — Administrator — Enterpreneur — Integrator — сокращенно PAEI. Адизес описал все в общем случае, мне же это интересно на примере команды разработки ПО. Только я позволю себе перевести названия ролей не дословно.

Стахановец — Producer

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

Ему важно что он делает, и как. С презрением смотрит на все что не помогает в его работе. Ну например багтрекер, отчеты о проделанной работе, письма и тем более все эти совещания. Зачем они ему? Он и так знает что он делает, что сделал и что дальше ему делать. И каждая минуты потраченная на эти, казалось бы, бесполезные вещи отнимает время от выполнения своей основной работы, что он очень не любит.

Бюрократ — Administrator

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

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

Изобретатель — Interpreneur

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

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

Политик — Integrator

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

Конфликт ролей

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

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

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

Помимо понимания зачем все это, что у нас есть и какой смысл это несет, самое главное что я вынес из книги для себя — это то что не нужно оценивать срок как таковой, пытаться угадать дату, нужно оценивать промежуток внутри которого наиболее вероятно завершение задачи, т.е. гораздо лучше что-то типа «с вероятностью 90% это сделаю от 1 недели до 5 месяцев», значит быстрее ну явно никак, только пистолет к виску приставить, и дольше будет только если случится что-то из ряда вон. Мы здесь ставим рамки проекта. Ну и по мере анализа, разработки и пр. можно давать более точную оценку, сужая этот промежуток, и в идеале реальный срок и эта оценка должны сойтись. Я конечно очень поверхностно идею передал, нужно понимать все тонкости и их тоже много, но суть примерно такая. Ну а вообще там много других оцень полезных мыслей, это лишь пример.

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

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

Требования к подобной системе просты:

1. На сайте сервиса читатель объявляет книгу, которую он в данный момент читает.
   По мере чтения, к примеру после очередной главы, он на сайте указывает время в которое собирается обсудить очередной блок.
2. Желающие побеседовать на эту тему, обсудить книгу или просто послушать умных людей подписываются на сообщения читателя (rss, ical и пр.). Т.е. главное чтобы все были проинформированы за несколько часов.
3. В оговоренное время читатель начинает голосовое обсуждение через skype. Там есть возможность проводить как конференции для нескольких равноправных участников, так и трансляция skypecast с голосовыми «вопросами из зала», по решению модератора (сумбурно объяснил, подробнее можно прочитать на сайте skype). Денег за это не просят.

Сам сайт технически легко настраивается на основе Drupal, буквально за день/два. Плюс заказать и прикрутить дизайн. Основная нагрузка ляжет на skype, поэтому с хостингом и пр. тоже сложностей нет.

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

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

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

P.S. Россия самая читающая страна в мире, или как?

Кстати, книгу можно скачать бесплатно, автор выложил ее в сети: http://sap.elashkin.com/

Вдогонку к этой книге можно почитать, если кто не читал, книгу «Блеск и нищета информационных технологий» Николаса Дж. Карра, чем то пересекаются, имхо.

Первой книгой я прочитал «Идея-вирус? Эпидемия!», Сета Година. От книги я ожидал немного большего, может потому что имя автора довольно раскручено. Нет, не то чтобы книга мне не понравилась, это я ожидал чего-то иного Я, наверное, ожидал подробное описания того, как действовать, как применить это к текущей ситуации, какие-то конкретные шаги или типа того. Немного из этого есть в книге, есть некоторые общие рекомендации и идеи, написанные между строк. Но большая часть этой книги посвящена тому, что же это такое «вирус», множество примеров и разжевывание всего этого с разных сторон, что, в общем-то, и так понятно. Главное что я убедился это в том, что к вирусному маркетингу нужен вирусный продукт
Вот, например, нашел почти все, о чем написано в книге: Пять элементов Вирусного Маркетинга

После взялся за «Партизанский маркетинг», Дж.Левинсона. Это меня уже удивило, честно говоря, я немного про другое думал, представляя партизанский маркетинг, но началось все с НЛП, что это и как использовать... Тут помимо этого много дельных советов, но, так или иначе, все сводится к этому Меня это даже отпугнуло на первых страницах, подумал что вот так, помимо воли, заставлять идти человека у вас на поводу это нехорошо. Автор знал о такой реакции, и тут же исправлял такое отношение. Нет, не используя НЛП(ну разве только частично), а просто показывая почему никто никого не обманывает. В частности, он предлагает показать клиенту, что мы полностью ему открыты, к примеру, предлагает и недостатки продукта показать клиенту. А вот как это все надо преподнести, чтобы это было плюсом, чтобы клиент остался, он и учит. И все это, как ни плюются в эту сторону, гораздо честнее, чем традиционная реклама. Разговаривать на том же языке, войти в доверие это не означает обманывать (иначе какое это доверие?), а вот, например, рассказы от лица «ассоциации чего-нибудь», о всяких супер скидках, о немереной крутости товара часто бывает не совсем честным. Повернутся лицом к клиенту гораздо прибыльнее, но и гораздо сложнее, чем снять очередной бессмысленный рекламный ролик. Та же идея проглядывается и у Сета Годена, он неоднократно горит о том, что вирусная реклама лучше и быстрее распространяется от уважаемого человека, которого знают и доверяют.

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