SoftwarePeople 2012 день первый

Сегодня был первый день конференции SoftwarePeople-2012. Конференция — определенно лучше, чем в прошлом году. Очень много интерактива, общения. Много интересных докладов, и среди них — есть новые имена, а это — важно. Так что в целом — превосходно.

Теперь — подробности. Для начала — об общем тренде, который я явственно зафиксировал на этой конференции. Это — работа как fun, а не как необходимая деятельность. Конечно, об этом я слышал и раньше, но это было где-то в теории, прекрасном будущем. А теперь, похоже, оно входит в жизнь, становится ее частью. Об этом говорили минимум в трех докладах: Дэниэл Льюис «Мотивация — залог успеха», Асхат Уразбаев и Дмитрий Евтеев (Positive Technologies). И, как сказал Асхат «не то, чтобы это мне нравилось, но это входит в жизнь и с этим надо считаться».

Кстати, если говорить о нашей компании (CUSTIS), то с этой точки зрения дело обстоит хорошо. Правда, вместо модного слова fun мы говорим о самореализации, что вносит свои оттенки, включая определенную сдержанность. Но тезис, что «Компания объединяет людей, самореализующихся в творческой практической инженерной работе в области информационных и бизнес технологий» (Володя Рахтеенко на стратегической сессии 2011) — звучит адекватно духу времени, хотя и не использует модных мемов.

Теперь про отдельные доклады.

Сергей Высоковских. Альтернативный метод визуализации хода IT-проектах. Блестящая, оригинальная идея по визуализации хода проекта через представление его в виде областей, подобно карте. Каждая область — задача, площадь пропорциональна трудоемкости, по цвету различаются задачи разных типов. По ходу проекта — закрашиваем: пунктирная граница — начали постановку, сплошная граница — можно реализовывать, заштриховали все — готово к тестированию, закрасили — протестировано. Новые задачи — дополнительные области, а вот доработки в ранее имевшихся — через закрашивание более темным тоном области пропорционально дополнительной трудоемкости. Плюс — звездочка с текущей оценкой ожидаемого срока завершения. И стрелки, показывающие порядок выполнения, на которых можно подписывать отдельных исполнителей — как на военных картах. Понятно, что тулы для рисования под это нет, потому — наняли студента, он рисует (в числе прочего).

В целом — эффективная и интуитивно понятная визуализация. Показывающая некоторые проблемы. Наглядная в динамике. Эффект — ход проекта в таком виде понятен не только ему как ведущему проект, но и руководству. В отличие от старых способов — диаграмм ганта, burndown chart, доски — они все их использовали. может быть потому, что студент рисует творчески — они пробовали сделать тулу, но там получились прямоугольники, и это совсем не то. Но в принципе в играх сейчас же замечательно порождаются карты местности, так что, глядишь — и тула получится 🙂 А тогда это сопрягается с системой ведения дел, любой. Потому как это не способ организации работы, это просто визуализация. Но — полезная, я знаю цену хорошим визуальным образам. И я буду пробовать использовать эту идею в своей работе.

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

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

Что замечательно — совсем недавно Рома Корешков рассказывал о статье 1992 года на ту же тему — Jack W.Reeves What is software design. По ссылке — оригинал, а здесь — русский перевод. Через 13 лет Ривз вернулся к тезисам статьи и нашел, что они сохранили справедливость.

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

Вообще список проблем — может применяться в очень многих случаях. Например, для наблюдения за деятельностью человека. Подходишь утром поздороваться, говоришь о погоде, потом спрашиваешь — какие проблемы? Он рассказывает. Потом — то же через неделю. Если проблемы изменились — значит все нормально, работа идет. А если те же — или у человека затык и надо помогать, или он ничего не делает. Могут возразить, что, дескать, сотрудник может просто выдумывать новые проблемы, но Влад говорит, что по его опыту легче начать работать, чем выдумывать каждый раз новые проблемы, сложно это 🙂 В общем, хороший доклад, надо смотреть презентацию и видео.

Остальные доклады — коротким списком, что запомнилось

• Асхат Уразбаев «Лидерство в стиле Lean». Говорил о 3 видах развития команд. Первые — идут вверх. Вторые — попробовали, но не сложилось, и тут — понятно, усилия оказались чрезмерными, но прорыва не принесли. А третьи — вышли на некоторый уровень и там колеблются. И таких много. Почему? Потому что у них кончились проблемы, работа пошла «хорошо». Если проблема возникает — они с ней борются. Но вот чтобы идти дальше, надо уже говорить не о проблемах, а о возможностях. Пробовать, экспериментировать. А без этого — не получится. Дальше речь шла о различных способах — что и как можно пробовать, но это — примеры, а не руководства. Но примеры — полезные, так что презентацию я тоже буду смотреть.
• Джефф Де Люка «Почему мы терпим неудачи. Разработка ПО в наши дни». Джеф дал авторское видение современного состояния. Там не было открытий, но это не было и изложение от капитана Очевидность. Это было авторское видение с полутонами и деталями, и от мэтра оно — интересно. Из неожиданного: изменения он видит всегда революционные, через хаос. А я так не хочу.
• Дэниэл Льюис. Мотивация — залог успеха. В докладе был список буллетов — что мотивирует английских разработчиков сегодня. Утверждалось, что не только английских. Размер зарплаты там очень далеко не наверху (но он должен восприниматься как справедливый). В целом — любопытно.
• Вадим Митякин «Путешествие по изведанному. Чем ваша компания является на самом деле». На этот доклад я не попал, пошел на Джефа. А, говорят, он был весьма интересным — о компании из позиции генерального директора, это редко бывает на конференциях.
• Василий Малинов (Oktogo.ru) «Роль продукта в успехе привлечения инвестиций» — об успешном стартапе, интернет-проект по резервированию отелей в России, взгляд на развитие изнутри. Как менялась бизнес-идея при сохранении в целом технологической платформы резервирвоания — они искали нишу рынка. Любопытно.

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

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

Завтра — второй день и, надеюсь, тоже будет интересно.