Архив за May, 2008

Встречаются как-то два психолога. Первый начинает разговор за жизнь:
— Я себе недавно купил навороченный Феррари…
А второй сначала косо смотрит на первого, а потом и говорит:
— Слушай, мы же все-таки профессионалы. Давай просто расстегнем брюки и померяемся!

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

Знаете, это реальная проблема на территориях пост-совка: к сайту компании у нас принято относиться не как к инструменту зарабатывания денег, но как к красивым картинкам и просто фактору престижа. Такой сайт приятно показать друзьям, коллегам, клиентам, жене, в конце концов… но стоит ли он вложенных средств? Да, сайты в экс-СССР стоят очень дорого, как для стран 3-го мира: совершенно реальна ситуация, когда компании, торгующие, например, сантехникой, платят за разработку сайта в Киеве или Москве дороже, чем их коллеги в Нью Йорке или Сан Франциско. Уверен, вы сразу подумали о Студии Лебедева, но на самом деле я имею в виду не только ее, а множество компаний. Кроме того, за рубежом САЛ знают, в основном, как компанию, занимающуюся промышленным дизайном, а не сайтами… Ну, не привыкли там платить за дизайн больше, чем он может принести. Как вы думаете, многие ли компании в России и Украине думают о том, какой ROI будет у их сайта: как быстро сайт окупится и окупится ли вообще?

При таких высоких ценах сайты ухитряются делать с отвратительного качества CMS‘ками, подчас слабее бесплатных Joomla и Drupal, а часто выбирают и просто отвратительный Bitrix…

В интернете можно найти минимальные цены ведущих веб-студий России за 2006 год, как вы понимаете, сейчас эти цены повысились.
А что делать? Ведь нужно платить дизайнерам, которые сделают эксклюзивный дизайн (возможно, и несколько макетов на выбор)… Скорее всего, макет еще придется дорабатывать — и утверждение макета может растянуться надолго… И все это время нужно платить менеджерам, потом верстальщикам надо сверстать макет, еще позже макет нужно будет прицепить к CMS’ке, вполне возможно, что эту самую CMS’ку придется под конкретный сайт доделывать. В общем, не с потолка цены берутся…

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

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

Представьте себе ситуацию: жители соседних деревень Виларибо и Вилабаджо открыли магазины авто-запчастей — с одинаковым ассортиментом, ценами и уровнем обслуживания. Вскоре оказалось: через интернет можно привлечь много новых клиентов. Деревня Виларибо обратилась в солидную студию веб-дизайна, где им за 100 наноюнитов в два месяца сделали сайт под ключ с эксклюзивным дизайном. По прикидкам жителей Виларибо, затраты на сайт должны окупиться через 12 месяцев. Жители деревни Вилабаджо быстро отреагировали: они пришли в студию поскромнее и заявили: «Пожалуйста, возьмите сайт магазина «Виларибо», измените название на «Вилабаджо», поставьте наш контент и все настройте». Через месяц всего за 25 наноюнитов владельцы авто-магазина «Вилабаджо» получили свой сайт — такой же, как у «Виларибо»…
Прошло полгода… В деревне Вилабаджо праздник — ведь их веб-сайт уже окупился и теперь стабильно приносит прибыль… А жители деревни Виларибо все еще «в минусе».

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

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

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

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

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

Успешно прошли

• LiveDev — интересный и приятный русскоязычный блог о веб-разработке, в том числе на Django. Побольше бы таких сайтов в рунете!
• Психологический журнал «Искусство быть собой» — за последние год-два я еще не встречал настолько качественного сайта о саморазвитии и «популярной» психологии. В отличии от большинства подобных сайтов радует авторский контент и отсутствие «тупых понтов» у автора. Надеюсь, Олег Сатов, автор сайта, и дальше будет продолжать в том же духе.
• Антикорпоратив.ру — сайт о бизнесе, корпоративной среде (вернее, о ее вреде), «лайфхаках». Наиболее полезен работникам больших бездушных компаний.
• Управление проектами в картинках — интересный менеджерский блог, о нем я уже писал в прошый раз.
• 4 конверта — блог о финансовом самоконтроле. Все сказано в названии. Интересный проект Макса Крайнова, недавно отделившийся от его основного сайта.
• ContraMarketing — толковый блог с наблюдениями бывшего маркетолога. Искренний и циничный.

Не прошли карантин

• SitePoint — крупное сообщество посвященное веб-разработке, управлениию небольшими интернет-проектами, маркетинге и дизайне в интернете. К сожалению, окончательно скурвился: минимум практических материалов.
• LUK!Around — блог о путешествиях. Испортился: вместо блога о путешествиях превратился в блог о Берлине, где в каждом новом посте содержится совсем немного информации — складывается впечатление, что автору не о чем писать, потому он так поступает. Странно, что совпало это с активной рекламой у Давыдова. Надеюсь, в будущем сайт снова наберет обороты.

Временно в карантине

• Иван Пирог в режиме онлайн — недавно открывшийся блог Ивана, организатора семинаров Exception. Он обещает писать статьи на темы самосовершенствования и самомотивации, IT-бизнеса. Пока что на сайте всего 3 статьи, но довольно познавательные. Уверен, сайт и дальше будет радовать качественным авторским контентом.
• Agile-сообщество Беларуси — с одной стороны интересный сайт про agile-методологии. С другой — пока не могу понять, стоят ли его статьи затрачиваемого на чтение времени.
• AGOGE — сообщество сильных. Блог с дурацким названием о личностном развитии современного человека. Пока не понятно, насколько он самобытен, время покажет.
• David Cramer — интересный и полезный с практической точки зрения блог python-разработчика. Много информации о фреймворке Django и шаблонизаторе Jinja.
• Mac OS от Винтика и Шпунтика — простой и забавный сайт о MacOS и софте для нее.
• Пепелсбей.net — сайт о верстке с приятным дизайном. Негатива не вызывает, но статей на сайте пока слишком мало чтобы сформировать окончательное мнение.
• Подлипенский Павел — Блог о технологиях и деньгах. В название все сказано. Молодой и интересный сайт об IT-бизнесе. Рекомендую!
• MediaRevolutiuon — добротный русский сайт о маркетинге в средствах интернет-медиа. Радует обилие статистики вроде «Мужчины в возрасте 18-34 лет — наиболее активные зрители видеоконтента в Сети, 74% опрошенных заявили, что смотрят онлайновое видео по меньшей мере раз в неделю. Треть опрошенных мужчин в возрасте 18-24 лет смотрят онлайновое видео каждый день.».

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

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

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

1. Пожалуй, самое главное, что удалось сделать — разделить один большой проект на целый пакет мелких и средних проектов, таким образом, каждая рабочая группа, состоящая из 2-5 человек, стала заниматься одним и только одним проектом.
2. Вместе с разделением крупного проекта на мелкие изменилась и стратегия коммуникаций. Теперь команды разработки и их тимлиды регулярно взаимодействовали лишь с техническими руководителями в США, решая тактические вопросы и согласовывая API, а с локальными руководителями проектов вывяли текущие проблемы. В свою очередь, руководители проектов общались между собой и с высшим руководством сугубо о вопросах стратегии, рисков, интеграции проектов и изменения состава групп, а технические руководители между собой решали сложные архитектурные вопросы, утверждали API и следили за документированием технических решений. Отойдя от формальностей, можно сказать — главной задачей руководителей проектов и технических руководителей стало устранение преград на пути своих команд и интеграция проектов, но никак не отчетность.
3. Часть команд стали проводить регулярные стоячие совещания, что было простым и дешевым способом для участников проекта «находиться на одной волне» и выявлять реальные и потенциальные проблемы своевременно. Без разделения «1 проект — 1 команда» это было бы невозможно.
4. Длину итераций увеличили с одной до двух недель и стали планировать их так, чтобы в конце всегда оставался запас в пару дней. Это частично позволило избавиться от постоянной гонки, в которой все чувствуют себя проигравшими — когда работаешь в нормальном ритме, то и ошибок допускаешь меньше.
5. Оценки сроков и планы перестали «спускаться сверху»: теперь оценки сроков задач проводилась их непосредственными исполнителями под присмотром тимлидов, после чего согласовывалась с руководителем проекта и техническим руководителем, которые, как правило, срок увеличивали, учитывая дополнительные риски и сложности.
6. Стали использовать средства Continuous Integration. Полноценного TDD у нас все равно не получилось, но удалось заставить разработчиков тестировать свой код и более-менее стабилизировать качество билдов продукта.
7. Ввели т.н. «development blogs», куда разработчики (реально — тимлиды) должны были каждый день записывать свои достижения и проблемы, с которыми они столкнулись. Эти блоги на некоторое время стали главным средством коммуникации удаленных команд (ведь они находились в разных офисах), кроме того, это заставляло разработчиков писать! Впрочем, когда объем взаимодействия между разными командами уменьшился, от блогов мы отказались для большинства проектов.
8. Постепенно мы разработали различные автоматические средства отчетности и оценки сроков (используя идеи evidence based scheduling Джоэля Спольски), реализовав их как Jira plug-ins. Но постепенно отказались и от ежедневной формальной отчетности. Вести ее можно было разве что по собственному желанию, чтобы лучше ощущать «пульс проекта». Руководитель проекта теперь отвечал строго за успешное окончание каждой итерации, а не за успешное бумагомарание.
9. Стали проводить ретроспективы (к сожалению, они проводились между руководством разных проектов без участия разработчиков) в конце итераций. Это не произвело чуда, но помогло увидеть проблемы с разных точек зрения и, конечно же, не наступать на одни и те же грабли дважды.
10. Ввели еженедельную оценку оффшорных команд людьми из главного офиса в США, где каждый мог по пятибалльной шкале оценить уровень коммуникации, качества кода и адекватного восприятия документации. Локальные руководители проектов получали информацию и видели, кто какую оценку поставил. Многим поначалу казалось, что это сделано с целью найти козлов отпущения и показать «вот мы тут белые-пушистые, а они там за океаном бездельники и мудаки». На самом же деле, все эти оценки позволяли увидеть, кто конкретно не доволен взаимодействием, после чего не гадать — а связаться с этим человеком и узнать, чем именно он не доволен и совместно с ним улучшить рабочий процесс. Медленно, но уверенно все это получилось. Как всегда в распределенной разработке, главная трудность — коммуникация, а самый трудно контролируемый фактор — фактор человеческий.

Выводы

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

А вы масштабировали agile-процесс? Если да, то как?