Игорь Артамонов

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

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

В книге The Lazy Project Manager есть небольшой фрагмент о том как Хе́льмут Карл Бе́рнхард фон Мо́льтке, германский генерал позапрошлого века, отбирал офицеров. Он разделил офицеров по двум критериям: умный-глупый и ленивый-энергичный.

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

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

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

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

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

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

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

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

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

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

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

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

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

Читать далее »»

Одной из последних прочитанных мною книг была книга «SAP Business One. Строим эффективный бизнес» Михаила Елашкина.
Несмотря на название я очень советую ее прочитать не только тем кто занимается продуктами SAP, и не только 1Сникам, а вообще всем кто так или иначе занимается разработкой или внедрением ИТ продуктов. Тут действительно много о том как построить эффективный бизнес, с применением информационных технологий конечно. И отнюдь не только лишь о продукции SAP, по крайней мере первая половина.
В книге хорошо описано что на самом деле нужно бизнесу, что последний требует от ИТ. Ведь, к сожалению. мы часто путаем цели и способы их достижения, сосредотачиваясь совсем не в том месте, не на решении бизнес задачи, а на реализации программного продукта. Поэтому полезно взглянуть на себя с другой стороны, в книге есть множество примеров реальных бизнес задач, ИТ решений, и правильных и не очень.
А вообще книга полезна не только ИТ специалистам, менеджеры, строящие тот самый эффективный бизнес, тоже много интересного найдут. Тем более что книга не переполнена техническими деталями, лишь в минимальных дозах, достаточных для освещения материала.

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

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

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

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

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

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

Прочитал замечательную книгу Тома ДеМарко «Deadline. Роман об управлении проектами». Читается на одном дыхании, особенно благодаря интересному подходу автора
Одна из немногих книг, которая может так просто и понятно показать по шагам весь процесс создания ПО, от проектирования до завершения. Очень хорошо раскладывает все по полочкам, вместе с героем книги проходишь все этапы, почти на практике Открыл для себя пару истин, которые вроде и так понятны, но гдето блуждали вдалеке и требовали обдумывания и доказательства.
Очень рекомендую для прочтения.

Помимо того что я программист, я получил некоторое экономическое образования, у меня доп. специальность менеджер. Но полученных знаний катастрофически не хватает чтобы применять это в работе, и я стараюсь это исправить, книги читаю, в том числе бизнес-тематики. Вот сейчас добрался до книги «Решение проблемы инноваций в бизнесе. Как создать растущий бизнес и успешно поддерживать его рост», К.М. Кристенсен и М.И. Рейнор.
Хоть книга и не имеет отношения к ИТ, но я хочу ее порекомендовать тем кто запускает новые собственные Web-проекты, start-up, и пр. инновации в ИТ. Написано думаю понятным языком, и для многих откроет глаза на то как надо поступать, как предсказать получится ли проект, или может и не стоит начинать.
В ней, например, объясняется почему не стоит напихивать в продукт как можно больше нужных и ненужных вещей, и пр., объясняя «10 правил для интернет-стартапов»