Книга описывает оригинальный подход к разработке веб-приложений компании 37signals и доступна бесплатно. Постулаты книги применимы и в других сферах деятельности.
После прочтения оставлется стойкое ощущение, что ее авторы никогда не работали в больших проектах и не понимают их специфики. То, что они в них работать и не будут – понятно из их философии.
Я сам противник большой бюрократии и многие положения классической теории управления проектами вызывают у меня отвращение. Но даже в моем скромном опыте есть проекты, к которым подход не применим.
В начале текста приведена ремарка, что “идеи этой книги не применимы к каждому проекту на этой земле”, однако число таких проектов гораздо больше, чем пытаются показать авторы книги. Пример “Даже Microsoft использует Getting Real, сомневаемся, что ваша компания больше них” некорректный – он используется для экспериментального проекта start.com. Было бы интересно посмотреть на результаты разработки Windows по этим принципам.
Не все продукты могут быть маленькими. И как только вы начинаете заниматься интеграцией и реализацией нестандартной логики взаимодействия – принципы перестают работать. Лучшее – враг хорошего, и когда вы решите перейти от ширпотреба к товару класса “люкс”, методы придется изменить, а продукт – переписать.
А ведь именно в люксовом сегменте находятся самые дорогие заказы, которые таким компаниям никогда не светят. Они, похоже что, этим и довольны – тогда просто стоит запомнить, что Getting Real – это подход для МАЛЕНЬКИХ компаний, не стремящихся стать большими. И в большой компании не получится разбить проект на мелкие кусочки и раздать множеству мелких разработческих групп, потому что один большой проект – это только не сумма нескольких маленьких проектов. И в почете уже будет находиться глубокая специализация и знание множества тонких моментов, в отличие от универсализации, проповедуемой 37signals.
Не могу с равнодушием смотреть на близорукость их подхода, когда перед глазами примеры, иллюстрирующие его тупиковость. Когда приходилось несколько раз переписывать разработку с нуля, потому что она отказывалась работать при более серьезных задачах. А подход “а мы сейчас по-быстрому напишем” привел к тому, что без необходимости одна и та же работа была проделана несколько лишних раз.
Кроме того, не поверю, что действительно можно эффективно заменить встречи общением по почте или тем более по instant messenger’aм. Конечно, если проводить неподготовленную встречу, она окажется неэффективной. Но, видимо, у разработчиков нет примеров действительно полезных встреч, учитывая описанные выше признаки отсутствия опыта работы в больших компаний, а также то, что необходмость повестки встречи подается как нечто неожиданное.
Неприятным моментом является перевод, который выполнен весьма некачественно, несмотря на призыв в тексте книги делать меньше, но качественно. Текст элементарно не вычитан – вкрапливаются элементы кода вместо букв, не говоря о несогласованности некоторых предложений, что оставляет впечатление детской поделки, а не серьезного текста.
Начинаешь даже по-иному относиться к самому тексту книги, когда видишь такие несоответствия: люди в комментариях просят навести порядок с переводом, а авторы книги, призывающие оперативно отвечать на входящие сообщения от своих клиентов, заняты, наверное, более важными вещами.
Остались непонятными и другие соображения. С одной стороны, осуждается сравнение с тем, что делают конкуренты (в частности, в форме таблиц), с другой – призыв подписываться на изменения продуктов конкурентов, чтобы оставаться в курсе событий.
Но тем не менее следует признать сильные мысли за текстом. За одну только мысль, что в треугольнике “сроки-бюджет-функциональность” нужно жертвовать функциональностью, нужно уважать эту книгу. Кроме того понравилось, вызвало одобрение и т.п., следующее:
- мысль про общее время работы, когда никто и ничто не должно отвлекать от дел. Впрочем, этот постулат тайм-менеджмента становится всё более расхожим,
- мысль про управление ожиданиями: не стоит угождать всем подряд. А о действительно необходимых изменениях вам будут постоянно напоминать посетители через форму обратной связи,
- фрагмент про большую важность умения выражать мысли письменно. Это действительно экономит время участников процесса и в конечном счете повышает эффективность разработки. Особенно, когда управление проектов проводится через форумы Basecamp.
В отличие от непонятных текстов с неочевидными связями, выдаваемыми за логичные; “водой” и отсутствия ориентированности на результат (например, как в блоге одного “тысячнега”, то выдающего себя за девушку, то нет). Читать вроде приятно, а пользы мало, - важность дизайна “чистого листа”. Действительно, мало кто уделяет этому внимание, в результате чего посетитель видит не то, что планировали разработчики;
- подогрев интереса к проекту до выпуска. Приведены действительно полезные советы, которые, судя по всему, используются в “Блогистане;”;
- повальная визуализация, красной нитью проходящая через весь текст. Подходящий фрагмент для описания: “В отличие от текста, который могут понять по-разному, дизайн интерфейса будет представлять то общее, с чем все могут согласиться.”
Общее резюме следующее – подход интересный и, безусловно, имеющий право на жизнь, но прежде чем применять его в своих проектах, стоит серьезно задуматься и не поддаваться манительной привлекательности управления проектами “в стиле фанк”.