Да, мы это сделали.

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

Последние несколько месяцев команда из почти 10 человек сотрудников Артикса (в том числе и ваш покорный слуга) трудилась над тем, чтобы воплотить в жизнь концепцию проекта. Изначально наши коллеги из UI Modeling ставили перед нами задачу: сделать сайт максимально настраиваемый для пользователя…
Требовалось настраивать блоки на стартовой странице, добавлять графики и настраивать биржевую информацию. При этом на сайте предполагалось собирать не только новости, но также описания компаний, отраслей, персон, выбирать и сортировать все это по регионам и городам.
Основная концепция проекта дожила и до сегодняшнего дня, но в процессе часто менялась конкретика. Мы писали и переписывали новости, импортировали базы данных с миллионами компаний, а потом убивали их. 3 раза менялись источники биржевой информации…

И вот в сентябре случилось 2 важных события в жизни проекта. Во-первых, было принято решение полностью переверстать проект, обновить дизайн; во-вторых, главным редактором БФМ стал Антон Носик — знаменитый стартап-менеджер. В результате нам пришлось не просто за 2,5 месяца переверстать 300 шаблонов, но также обновить почти все JS скрипты (а их несколько десятков), переписать модуль новостей, подключить новые источники информации, научиться управлять архивом данных, автоматизировать обновление проекта.
Команда проекта 2 месяца работала практически без выходных. (За что им конечно безмерный респект.)

В чем ключевые особенности БФМ. Чем же он так технологически интересен?
В рунете уже появляются проекты с настраиваемым интерфейсом. Например, dni.ru копирует часть функциональности сайта BBC и позволяет скрывать/раскрывать блоки, добавлять в них количество новостей. Но БФМ первый новостной ресурс, который позволяет выводить на стартовую страницу любую интересующую ленту новостей, поставить ее в нужном месте, скрыть или раскрыть. Вы можете читать новости по определенному разделу (Финансы или Промышленность), или же добавить на стартовую новости по компании Газпром. Вы можете читать самые популярные новости или самые комментируемые. А можете читать ленту новостей BBC или ИноСМИ. Вы даже можете добавить свой собственный RSS и читать его с сайта БФМ.
Для всего этого требуется использовать “Каталог источников информации”, а будущем мы добавим кнопочки на каждую ленту новостей “читать на главной”.

Вы можете смотреть биржевые индексы, курсы валют и кучу других циферок. БФМ вгружает в себя информацию по изменениям более 3000 финансовых инструментов. Уже сейчас он хранит в себе архивную базу по некоторым из них за 20-40 последних лет. Нам еще предстоит отработать интерфейсы взаимодействия пользователей с таким архивом.

Скоро пользователи смогут сами настраивать блок биржевой информации под себя.
Каждый пользователь может зарегистрироваться на проекте, комментировать новости, настроить стартовую и работать с ней с любого компьютера. При этой кастомизации мы должны были обеспечить высокую производительность системы. Мы рассчитывали не менее, чем на 100 000 посетителей в сутки. Изначально в ТЗ первой версии сайта было предположение, что сайт должен выдерживать не менее 100 000 показов страниц в сутки. Первый день работы портала показал, что эти цифры были даже пессимистичны — портал перешагнул 100 тысяч к концу первого дня!

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

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

За прошедшие 2,5 месяца мы провели огромную работу и успели в срок.

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

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

Так вот: это логика неудачников. Пусть эта фраза в голове того кто этого еще не понял застрянет занозой. Да это логика неудачников.

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

• Когда я в последний раз писал полноценный документ?
• На сколько глубоко я документирую свой программный код, задачи, тесты?
• На сколько грамотно и связно я умею писать по-русски (английски)? 0..5
• На сколько хорошо я знаю инструменты для написания документов: Word, Wiki?
• Как я оцениваю свою способность писать документы? 0..5

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

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

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

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

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

Учимся мы для себя.

И если в детстве это было понять сложно, то став полноценной личностью это наконец должно доходить.

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

Как мы это готовили.

Первый вопрос, который рождается при взгляде на название конференции: “Почему Summer? Конференция же проходит в сентябре!”  Да это истинно так, в сентябре. Но. Задумана она была в мае.  Как следствие, мы планировали провести ее в июне, потом в конце июня, потом в июле, назначали на август… Но лето сезон не предсказуемый. То один из организаторов уходит в отпуск, то другой…

2 сентября, сразу после моего отпуска, мы собрались на обед в кафе с Денисом Петелиным и Пашей Габриелем. Денис объявил: “У нас 2 варианта: или мы проводим конференцию 19 сентрября или мы все “земляные черви”…”  Единогласно был принят первый вариант развития сюжета. 

У нас было 2 недели. И что интересно все получилось. Сделали сайт, привлекли спонсоров, пригласили участников, сделали стиль и раздатку, провели организационные мероприятия, пригласили интернет-телевидение. На самом деле много работы. Кто в курсе оценит.

В итоге конференция получилась чуть ли не беспрецедентной среди подобных по уровню докладчиков. Из 14ти докладов почти половина профессиональные тренеры или лекторы. Аудитория набралась почти под завязку. Иногда было не просто протолкнуться на кофе-брейках. 

Доклад.

Изначально я предложил 2 темы, по которым мне было что сказать:

• Инфраструктура Agile-проекта.
• Психология в Agile.

Коллеги единогласно поддержали тему про психологию. Вот основные тезисы того, что я попытался донести до зала:

• В методиках Agile большую часть занимают вопросы психологии и управления команды.
• Внедрение Agile в компании это изменения, которыми нужно управлять, это изменения, которые будет внедрить не так просто из-за свойственной людям психологической инерции.
• Поэтому мы рассмотрели методы продавливания инерции.
• Человеческий фактор в гибких методиках, почему от него стараются избавиться и какой тип работников лучше всего подходит для работы в среде Agile.
• Мотивация и потребности. Набившая оскомину пирамида Маслова и типы мотивационных стимулов.
• На финал: “Джедайские практики Жестокий Agile”. Agile в аналогии войны. Стабильная и нестабильная системы управления.

Мою презентацию вы можете скачать здесь: Психология в Agile-проекте (.ppt ~3Mb).
Видео можно найти где-то здесь: http://itv.by/showvideo/showfromindex/15308.html.

Впечатления.

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

Пашу Габриеля и Асхата Уразбаева завалили вопросами. Один выступал первым, второй последним поэтому им и досталось больше всех остальных. Очень порадовал Денис Петелин, он со своим бутербродом войдет в историю, потому что красиво и удобно показал что значит работать по спецификациям и в чем в этом смысле прелесть agile. 

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

Что дальше.

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

По докладам. Презентации будут все выложены на сайте сообщества Agile.by. Иногда с этим сайтом бывают проблемы, но в самом скором будущем мы все с ним направим. Видео также будет выложено, когда будет полностью обработано.

Ссылки:

• http://agilesummer.org/ – сайт конференции AgileSummer 2008.
• http://www.happy-pm.com/blog/?p=133 — отчет Александра Орлова.
• http://picasaweb.google.ru/askhat/AgileSummer08# — фотографии Асахата Уразбаева.
• http://picasaweb.google.com/mazanik/AgileSummer2008# – фотографии Юры Мазаника.
• http://nikita-syskov.livejournal.com/220608.html – отчет о конференции.

Всю интересующую информацию можно прочитать на официальном сайте: http://agilesummer.org. Мы еще полностью не доделали сайт, но там уже размещена требуемая информация и есть возможность зарегистрироваться.

Я готовлю доклад про психологию в agile. Тема как-то обойденная вниманием, как правило больше говорят о технологиях и процессах.

Вот что случилось со статистикой подписок на мой сайт после обновления Wordpress до версии 2.5. в начале этого месяца. RSS поток поломался и в итоге осталось лишь 130 подписчиков.

Вчера я обновил сайт, сменил дизайн. Восстановил работу RSS. Сегодня с утра даже нашел баг в Wordpress, который мне не давал запостить эту картинку. Если вдруг кто-то отпиcался, то подписывайтесь снова: RSS-feedburner.

На прошлой неделе прошла 3-я по счету встреча Agile-сообщества Беларуси (agile.by). Павел Габриель, мой друг и товарищ, читал доклад на тему “User Stories - Написание, отбор, оценка”. Их небольшая команда действительно накопила определенный опыт в составлении и управлении пользовательскими историями, который было интересно послушать. Надеюсь, что в самом ближайшем будущем на сайте сообщества будет выложена презентация Павла.

Вообще, управление user stories посредством доски и карточек лично для меня представляется весьма интересным. Вот в каком плане. Иногда ко мне обращаются знакомые и друзья с просьбой помочь им в выборе системы управления проектами. Проблема формулируются обычно так: количество проектов увеличивается, процесс разработки выходит из под контроля, задачи теряются. Значит требуется система управления проектами. Мое мнение в этой ситуации таково:

Пока менеджер и команда не знают своего процесса настолько, чтобы управлять им с помощью простейших средств (Excel, маркерная доска, “бумажные истории”), — никакая система управления не даст им знания процесса.

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

О следующей встрече сообщества будет объявлено дополнительно.

Исходя из задач клиента мы определяем ключевые вехи, которые говорят что к “такому-то числу должно быть готовы такие-то вещи”. Под них строится и весь процесс работы. Он может отличаться в каждом конкретном случае, но в целом придерживается следующей схемы.
http://www.jvetrau.com/2008/07/01/proektirovanie-v-agile…

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

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

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

Заказчик:
– О! Agile позволяет всегда видеть что делается в разработке. Теперь-то они не отвертятся, что мол релиз будет готов через месяц! Я смогу лучше контролировать их работу. Только не на этой неделе… все дни расписаны, а на следующей неделе конференция 3 дня. Пусть работают, а там через месяц время найдется.

Менеджер проекта:
– У Agile низкие риски и высокий профит. Мы больше и стабильнее заработаем, а моя премия вырастет. Круто.

Программист:
– О! Если мы начнем работать по Agile, они перестанут сваливать на меня всю вину, что я не правильно прочитал ТЗ. А в случае чего мы подкорректируем оценку часов. Мне больше не парят мозг.

Тестировщик:
– Да вы все с ума сошли! Документации толком нет, но все должно быть сделано качественно! У меня даже нет времени тестировать с той скоростью, с какой вы все переделываете!!!

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

Мы уже провели 2 встречи. Сделали сайт. И планируем следующее общение.

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

Следующие встречи постараюсь анонсировать тут.

Давление бывает как положительным, так и отрицательным. Отрицательное это не что плохо или не цензурно звучит, а то что разрушает. Положительное давление соотвественно должно усиливать команду. Так, например, обкладывание матом строителей действует весьма положительно. А принуждение младших товарищей играть в “контру” в офисе разлагающе и вредно.

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

Перейдем к примерам.

Примеры внутреннего давления.

Ветикальное давление снизу вверх (встречается редко, часто корыстно):

- Юра, давай купим жалюзи! Солнце по утрам в глаза…
- Да-да, я посмотрю, что там у нас с бюджетом на текущий квартал…

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

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

Горизонтальное давление:

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

Также стоит привести примеры внешнего давления.

- Нам необходимо, чтобы вы запустили обновленный модуль конвертации валенков в пятницу!
- Обновление модуля поставлено в план. Вчера мы проводили планирование, на котором была произведена подробная декомпозиция задач по модулю конвертации валенков. В частности нашим ведущим программистом были вскрыты некоторые проблемы архитектуры, которые требуется решить прежде чем имеет смысл переходить к данному модулю. Это и обертка базы данных и класс обработкизащищенного соединения… Кроме того, текущий рефакторинг кода ядра системы будет закончен к следующему вторнику. Тогда же мы планируем получить от отдела аналитики результаты проектирования и дизайна модуля валенков. Следующее регламентное обновление программной части сайта запланировано на послеследующую пятницу…
- Б%#$ь! Модуль должен быть в ПЯТНИЦУ!!! У нас презентация! Иначе мы не оплатим вам работы по этому месяцу. ту-ту-ту…

Как мы видим давление внутри компании это то, что окружает нас каждый день.

ЗЫ. Первая серия тут.

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

Суть в чем. Программисты считают свою работу творческой. Но абсолютная свобода для творческой личности губительна. Возьмем художника, освободим его от всего, дадим ему сколько надо денег и скажем: Твори! Ни-ичего не сделает. Художнику нужны ограничения и запреты, внешнее давление, чтобы его преодолевать. Совершенно свободный творец, как правило, творец бесплодный. Кажется Петрарка говорил, что “художник должен быть всегда полуголодным”.

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

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

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