Текущая версия на 23:52, 14 апреля 2013

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

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

Иностранные докладчики в этом году, увы, не порадовали. Они все в прекрасном и великом прошлом, которое знают энциклопедично. А настоящее - больше на уровне трендов и мемов. Доклады подтвердили впечатления от мастер-классов Йордана. Ну, будем надеяться, что в будущем будет лучше - ведь был же в прошлом году Джефф Де Люка, а в позапрошлом - Нил Мейден и другие.

Сам я выступал на конференции, рассказывал об опыте применения Domain Driven Design. Прямое отражение модели в код на основе шаблонов Domain Model и Rich Objects, о котором говорят авторы подхода, вызывает в больших многолетних проектах определенные проблемы, и для их решения мы разрабатываем в проектах набор более сложных правил отражения, который назвали Технологическими рельсами. Доклад вызвал интерес, были вопросы. И еще из нашей компании выступал Коля Гребнев, рассказывал о создании самоорганизующихся процессов в командах. Его доклад тоже слушали с интересом.  

А теперь о докладах подробнее. Надо учитывать, что я был далеко не на всех докладах. Я пропустил Кириленко потому что мой доклад стоял параллельно. Не был на Орлопанках, слушая параллельный трек - там были наши ребята и, я думаю, они донесут ценное, что там было. Еще был большой трек Microsoft ALM, о котором я знаю из других источников и трек мобильной разработки, которая (пока?) вне сферы моих профессиональных интересов, туда я зашел только на Дмитрия Мартынова из Google чтобы почувствовать тренды. А еще во второй день мне пришлось уехать в 15 часов, увы.  

Особенно понравившиеся доклады

Дмитрий Безуглый (Системный подход) Варианты и инварианты в управлении людьми. Что такое хорошо и плохо для руководителя команды, проекта, отдела и компании

Зал полный. Дима опоздал минут на 5, но люди его все равно ждали и даже подтягивались из других залов. Так что я тоже не уходил посмотреть, а держал место :) Пришел и стал сразу троллить зал - вы что тут все в топы компании собрались? Зал откликнулся и доклад в целом шел с хорошим интерактивом.

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

Важно, что стили управления надо не только знать, надо понять, какой из них наиболее подходит тебе самому и уметь им пользоваться. А это - не так очевидно. Правда, подробно про стили управления Дима не успел :(

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

Характеристики эмоционального интеллекта.

• Самосознание. Единственный инструмент - это мы сами. И руководитель без него долго не потянет
  • Уверенность в себе
  • Реалистичная самооценка
  • Умение посмеяться над собой.
• Самоконтроль. От знания к действиям.
  • Надежность и честность
  • Спокойное отношение к неожиданностям
  • Признак открытости новому
• Мотивация
  • Оптимизм даже перед лицом неудачи
• Эмпатия
  • Уважительное отношение к чужой культуре
  • Предупредительность по отношению к клиентам и потребителям.
• Социальные навыки
  • Умение убеждать
  • Владение искусством руководства коллективом, навык его формирования

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

Что делает 3-летний ребенок, которому подсовывают невкусную еду? он говорит "еда отвратительная". У ребенка только одна точка зрения. У многих остается до 40 лет. И получив шишку от новой ситуации, говорят "все новое плохо". Другие говорят про урок опыта "я получил урок на 20 млн. долларов. Дороговато, конечно."

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

Шесть базовых стилей управления, каждый со своей стрункой. Каждый завязан на ключевую потребность подчиненного-последователя. Записать я не успел, но, насколько я понимаю, российским источником по этому является статья "Многоликое лидерство" в "Вестника McKinsey" N6 (2004), перепечатанная на многих интернет-сайтах и предлагаемая для скачивания. На основном сайте нужна регистрация, и вот еще две ссылки: 1 и 2, в первой верстка - лучше, но таблицы даны как картинки. Статья начинается с того, что эти шесть стилей основаны на разовом опросе 6000 руководителей. Но дальше, после характеристики, говорят, что успешные руководители используют несколько стилей и сами переходят с одного на другой, в том числе внутри коммуникативных актов. Таким образом, сами стили не получены опытным путем, а сформулированы на основе анализа эмоций, к которым они апеллируют. В разных ситуациях уместны разные эмоции и подходы, и многое тут зависит от личностей людей - соответственно, классификация носит характер помощи руководителю для осознания своих действий, и не менее успешно может применяться подчиненными для тех же целей.

Сергей Мартыненко. Влияние вариаций на ход проекта и методы противодействия увеличению срока

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

Сергей - из тестировщиков, потом аналитик, PM, архитектор... Знает, как артефакт будет востребован его потребителями. Он рассматривает план - отдельно, как список работ и промежуточных результатов и отдельно от плана - календарный график с оценками трудоемкости и сроками.

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

Были эксперименты, которые показали, что фактическая скорость выполнения задач не коррелирует с личностными характеристиками (например, IQ), а также с опытом. Кроме того, было выяснено, что люди не могут априори оценить сложность задач - даже качественная оценка не совпадает с фактической, плюс на разных задачах производительность пары разработчиков местами. А размах по производительности - 10-кратный. Эксперименты (вроде) конца 60-х - начала 70-х, а потом были как-то повторены в 90-е. Что означает, что об оценке можно говорить только применительно к конкретным разработчикам и задачам, и только как интервал. В то время как трудоемкость часто хотят получить без исполнителей.

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

• Когда неофиту сообщают "оценка есть" - он верит и фильтрует окружающий мир.
• Вторая - давление группы, "обе пирамидки белые". Не только дети, но и взрослые. С кашей - сладкая каша.
• А третье - вера убеждения, двоемыслие. Распознать человека с двоемыслием очень просто. Он всячески сопротивляется даже мыслям о проверочном эксперименте.

Пример, мем советской армии - спичка горит 45 секунд. Хотя у каждого офицера - часы и спички. И никто не проверял. Хотя реально 25 секунд - искусство, большинство 10-15.

Менеджеры - люди, они всему этому подвержены. И с этим нельзя бороться, но хотя бы надо учитывать.

Второй разрыв шаблона - из теорвера. С параллельным исполнением работ. Пусть проект декомпозирован на 5 независимых работ, на каждую назначен отдельный исполнитель и каждая работа оценена в 2 недели в вероятностью 50/50 (то есть 50%, что она займет не больше двух недель). Спрашивается, какова вероятность, что проект завершится за 2 недели? Правильно, 1/32, то есть 3%. А вот какой будет срок. чтобы завершение проекта тоже имело 50% вероятность? Как следует из теорвера, он соотвествует 87% вероятности завершения одной работы. Что учитывая пуассоновское или лог-нормальное распределение (ссылка на Бибичева "Пуассоново горение сроков"), мы имеем 5.5 недель. Ну-ка, кто из менеджеров примет такую оценку?

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

Заметим, что практически когда проект не завершится во-время, никто не вспомнит про теорию вероятности. Все будут уверенны в неверной оценке работ и сошлются на объективные обстоятельства или на дебила-исполнителя, совершая фундаментальную ошибка атрибуции: чужие факапы объясняются их недостаками (идиоты!), а свои - внешними обстоятельствами. Частный случая - я д'Артаньян, а все (сверху, снизу, сбоку - идиоты).

Какие способы борьбы?

• Закладываться много
• Говорим: 5 запускаем, но 2 не сделаем, а одну - плохо, просесть по качеству
• Берем оценку с нулевой вероятностью. Спрашиваем трудоемкость (срок), за который точно не успеешь. Сжать график и делать 30% буфер. Но он не пробовал, пока полагает, что достаточно 50%
• Не давать исполнителю оценивать трудоемкость и не сообщать ему оценку. Втемную - график + буфер.

С работой без оценки - согласно ДеМарко и Листеру наибольшая производительность, если оценку не знаешь. Тогда 12. Если давал менеджер - 6.8, если сам - чуть больше, если системный аналитик - 8.6. Всем пятерым говорим "просто делайте". Тот, кто сделал первый - переключается на другую задачу. И начинает делать ее в параллель с самого начала, без координации - и вероятность успеть увеличивается :) Тойота на это идет, R&D - до 70 проектов.

Меня заинтересовало, после конференции я попросил у Сергея ссылку. Это ДеМарко и Листер "Человеческий фактор: успешные проекты и команды", глава "Еще раз о законе Паркинсона". Только вот о методике исследований там ничего нет, они ссылаются на статью Jeffery and Lawrence "Managing Programming Productivity" (Journal of System Software vol.5, 1985). Зато сам результат представлен последовательно, чтобы подтвердить мысль автора, при этом даже единица измерения продуктивности - не указана. В такой форме мне, честно, даже не интересно копать источник. Впрочем, желающие могут это сделать.

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

Максим Дорофеев (Касперский лаб) Алексей Пименов (R-Style) Мастер-класс «Симуляция аттестации»

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

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

Аттестация: "Понять целое, увидев часть должен ты".

Дальше была проведена игра в красные бусы с IT-антуражем. Мат.модель программиста - чистый детский носок с шариками, синими (хорошими) и красными (багами). Написать код: вытащить 8 шариков. Вынули код, посмотрели, вернули шарики и перемешали. 3 команды, 5 операторов носков в каждой и 2 тестировщика - зафиксировать, сколько багов, и еще менеджер, который следит. Дальше вытаскивают шарики и фиксируют на экране. А потом по результатам пробуют провести аттестацию - online-голосование зала. Интересно, что по результатам недели и по результатам 2 недель - голосование поменялось. Хотя исходный набор носков одинаков. А потом носки вскрывают и выясняется, что внутри всех носков наборы шариков одинаковы. То есть реально выдавали премии и наказания за вариации. И после этого была практика по заполнению карт Шухарта на полученных данных. Они позволяют выделить особые случаи.

Из реплик:

• Все KPI - чтобы дать меньше. А чтобы дать больше - просто дают.
• Вы работаете или вы менеджер

В целом реально получается массовый мастер-класс - весь довольно большой зал.

Дмитрий Мартынов (Google) Качественная мобилизация приложений: Цифры и факты

Мобильные приложения - безусловно тренд. При этом появляется много приложений как для конечного потребителя, так и enterprise-приложений, типа банк-клиента или приложений для сотрудников. Но при этом во многом авторы не задумываются особо про особенности и возможности мобильного приложения и, фактически, делают разработку, отдавая дань моде или потому что положено. А некоторые вообще видят потенциальный способ быстро заработать без особых размышлений. Как следствие - приложение не достигает своих целей, а то и вообще получается нефункционально, например, со скроллбарами в 3 пикселя, в которые невозможно попасть. При этом во многих случаях существенное улучшение (в разы) дает простая перестановка кнопок и экранов, или просто следование гайдлайну. Вообще Дмитрий наблюдает парадокс: почти любое приложение, написанное в соответствии с гайдлайном вызывает большой шум и оказывается удачным. Зачем, спрашивается, люди самовыражаются себе во вред?

Конкретные советы.

• Акценты, отличающиеся разработки мобильного приложения от обычного. SoLoMo: коммуникации, определение места, мобильность (=всегда с собой). И их надо держать в голове при проектировании.
• Надо определяться с целевой аудиторией и спектром экранов (мобилка и/или планшет)
• Качество: Дизайн, Родной интерфейс (кнопки на тех же местах и прочее), Ненадежные каналы, Энергопотребление.
• Для b2c - еще качественная промо-графика и текст в магазине приложений. Не начинайте с рейтинов, не рассказав зачем вообще приложение.
• По платформам. html-5. более-менее переносимо, только есть phonegap. Нативность. Бизнес-логику можно на Java писать и переносить (местами). Но интерфейс - нативный, нет одинакового.
• Услуги тестирования в отдельных компаниях, у которых есть все девайсы. Потому что совместимость - ограничена.
• Аналитика использования приложения - сервисы. Только надо осторожно, чтоб не перегружать. Плюс были кейсы, когда в библиотеки для анализа, которые разработчики встраивали в свои приложения, были закладки, которые начинали плохо вести, типа отсулки платных смс. Но кейсы, когда перестановкой экранов или кнопок увеличивали покупки в 3 раза.
• Мобильность и облако. Надо ли делать серверную часть обязательно в облаках. Однозначного ответа нет. Но! надо об этом думать на этапе проектирования, а часто люди сосредоточены на мобильной части и от серверной части не думают. А там часто есть даже комплиментарные сервисы.

Вывод. Пользуйтесь трендом BYOD, меняйте менталитет на мобильный, используйте опыт успешных, читайте гайдлайны по качеству.

Александр Бирюков (2ГИС-Онлайн) Как организовать мозговые штурмы применяя теорию ограничений

В докладе был рассказ том, как люди применяют к своей работе теорию ограничений через мозговые штурмы. Конкретно - про построение Дерева Текущей Реальности. При этом получилось сформировать достаточно конкретную и компактную инструкцию, как это делать.

Итерации, каждая не более часа. Обычно требуется 3-4 итерации.

• 1 итерация - список НеЖелательных Явлений. Координатор + 5-6 специалистов в проблемах. Самоклеющиеся стикеры.
• 2-... итерация. Выстроить причинно-следственные связи. Координатор + Эксперт-аналитик + 1-2 специалиста в проблемах. При построении дерево дополняется (другим цветом). И классифицируем. Часто на 2 итерации дерево удваивается - раскручивание причинно-следственных связей добавляет новые причины.
• Последняя итерация. Выверка дерева. Эксперт-аналитик + Координатор + Докладчик + Оппонент. Докладчик - тот, кто будет представлять.

Эффект - быстрая прорисовка картины.

Кейс с выходом в другие страны. Достаточно большое дерево, показано с размытием. Зона контроля и Зона влияния. Дерево надо делить. И Зона влияния - передается соседям, которые влияют (другая команда).

Advanced level

• на основе Дерева текущей реальности выстроить Дерево будущей реальности. Чтобы понять, не возникнут ли новые проблемы.
• Дерево разрешения конфликтов - когда в основе есть противоречие
• Дерево перехода
• ...

Докладчик уверен, что мозговой штурм - на конфчиках пальцев. Соответственно, предлагает усовершенствования, продвинутую методику. Или наоборот, способ организации применения теории ограничений посредством их.

Литература. Детмер "Теория ограничений Голдратта". Там хорошо и доступно изложено.

Области использования: в процессе; ретро (коллективно!); цели подразделения; цели личного развития.

Вопрос: а что делать, если есть несогласие экспертов о причинах и наблюдаемых явлениях. Ответ: можно эту часть отложить, провести исследования. Дополнение: можно решить, что несогласие двух экспертов - отдельная проблема, нарисовать дерево.

Идею использования - вбросил руководитель тимлидам, но кто заинтересовался - применяют.

Еще есть штука "непрерывная ретроспектива" (Дорофеев), они не пробовали, но планируют. Идея в том, что дерево висит на стене, в фоне - докидывается, иногда и перестраивается.

Александр Шишенин (Mail.Ru Group) Наемники борются за выживание, волонтеры — за победу

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

Как согласовывали

• топ-5 проблем каждый месяц. И человек мог вызваться быть координатором по решению причины (в фоне).
• выбор хранителей рас. Потому что нужно не только внешняя составляющая, но и эмоциональный контент. Там пошла эволюция, типа преобразование орков в агрессивных футбольных фанатов, а эльфов в гламурную молодежь. И в результате в игре игроки выбирали подходящий социотип и вырезали другой с удовлетворением.
• Появление драйверов. Выбирает фичу и вкладывает душу. Тот, кому нравится именно эта фича (PVE (бегать за мобами), например, против PVP (человека на человека)). Бывает, что драйверов фичи нет. Но: если команда достаточно покрывает социальную выборку, то какова вероятность, что эта фича будет нужна? В общем, не делаем.

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

У драйвера нет административных полномочий, но если фича не помещается в планы подразделения, то они вместе с лидом их смотрят "Все мы знаем, что когда смотришь на планы, там появляется НЛО, которое можно заменить нужной фичей".

У системы драйверов есть позитивный побочный эффект - лиды выходят из таких драйверов. Потому как опыт менеджмента и уважение в команде.

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

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

Практики о конкретных проектах

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

Степан Колесников (2ГИС) Преемственность продуктов

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

Светлана Гончар (Касперский лаб) Роман Ивлиев (Касперский лаб) Аквариум своими руками или курс молодого эксплуататора

Обычный путь. Надо-написали-поработали-выкинули. Еще есть: вместо выкинули: поработали-доработали. А еще - выкинули-купили такое же. А еще есть вариант купили-фигня-доработали-и еще доработали.

Метафора. От маленького аквариума с одной рыбкой - потом 50-100 литров - потом морской аквариум - потом аквариум для акулы. При этом нарастает эксплуатация, да.

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

Системная зависимость

1. К одной прикрутили вторую, но они зависят не слишком
2. Когда системы перекручены намертво
3. Когда системы слились неразрывно, и ввод новой не означает вывод старой, провязанные интеграционные системы...

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

Елена Журавлева(HFLabs) Жизнь после внедрения

Учредитель и технический директор. Компании 8 лет. Компания 35 человек. Более 50 клиентов, из них 35 постоянных. Коробка с большой кастомизацией, кастомизируют они, но умеют обучать заказчика. Область деятельности - интеграция и очистка данных.

Рассказ - хороший. Народа мало (около 30) потому что конкуренция с Орлопанками. Активный интерактив с залом.

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

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

Дальше немного тезисов.

• Часто с обоих сторон людей считают глупыми. Это неправильно.
• Смена ключевых контактов в крупном заказчике может разрушить отношения. это - риск.
• Конкуренты. Они всегда есть. У них крупные заказчики - Сбер и подобные. Конкуренция поддержкой.
• Решение у них - account manager. Надо иметь целостную картину и общаться не только с ИТ, а и с бизнесами... И для них это было открытием.
• Еще: в конце года объехать всех заказчиков. А то бывает, что проект идет, в команде все хорошо, только заказчик недоволен.
• Документируйте все. Как интегратор-разработчик ответственно говорит. Платформы у себя и заказчика, номера релизов, решения на статус-митингах, вопросы заказчика...
• Используют Confluence. В confluence пустили заказчиков. Есть отдельная презентация чем confluence отличается от word, она сама ездила к заказчикам.
• Профессиональная команда поддержки. Это важно. Срок жизни 5 лет часто потому, что заказчик задалбывается с поддержкой. Особенно тяжело с западными вендорами, особенно скорость реакции - они как интеграторы это знают.
• Проблема внезапных изменений API без преемственности. Не злоупотребляйте.
• Заказчик плохо относится к изменению ставок. Надо контролировать стоимость поддержки.
• Устаревший продукт. В том числе - только по мнению заказчика, потому что коммуникации нет.
• У них команда поддержки и команда разработки - одно и то же. И это правильно.
• Product manager. На самом деле, не один, а триада (Бесков). У них Технический + Маркетинг.
• Риски поддержки: интегратор. Там тоже меняются ключевые лица и так далее... Надо учитывать бизнес-модель интегратора. Многие из них плохо относятся к дешевым и красивым продуктам - на них не заработаешь. Из зала были реплики, что некоторые думали про специальную дорогую версию для интеграторов.
• Все-таки, вы работаете на заказчика, а не на интегратора. А еще надо взвесить плюсы и минусы. Их интеграторы не любят, но заказчики - любят и навязывают.
• У них глубокая кастомизация - тоже плюс, относительно западных вендоров. Но в целом стараются направить в нужное архитектурное русло.

Дмитрий Новоселов, Наталья Желнова. Безнадежные проекты: темная и светлая стороны пути самурая

Успешные проекты 1/3. Свежая статистика 2011. 44% - серьезные отклонения, 24% - неудачи. Поэтому 2/3 вероятности, что вы попадете в такой хреновый проект. Надо быть готовым. Дальше была некоторая теория, но она не очень интересна, по-моему.

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

Начал с кадров, сам мониторил HH и организовывал обучение параллельно с работой. В основном учили Java-разработчиков писать запросы - они почему-то не умеют, а нужно, ORM недостаточно. Поставили процесс. Сделали делопроизводство по хотелкам - TFS. Новые хотелки - через только через аналитиков. И предсказуемость результата. Поставил нормальный итеративный процесс взамен хаотического. Месячные итерации, быстрее не получилось из-за накладных расходов на релиз. При этом вниз - не залезал. У них несколько отделов, и пока через показатели видно, что работа отдела идет нормально, он в работу руководителя не вмешивается.

Видение правильного ведения проекта.

• Кадры решают все. Подбор. Частично подходящий и подтягивать. И стимулирование, материальное и нематериальное. Напрмиер, ты будешь наставником, потому как опытный. Или ты хотел развиваться в менеджера - будешь работать с субподрядчиком.
• Каждый солдат должен знать свой маневр. Регламент разработки. Система учета заданий. Конвейер обработки.
• Обязанность градоначальника - помогать. Не микроменеджмент, но быть готовым помочь. "Похвала также необходима писателю как канифоль смычку виртуоза". Забота о подчиненных - быт, и его тоже надо налаживать.
• Best pracices. Текущий объем не больше возможностей, давить незавершенку (не больше 2). Канбан. Оптимальный размер итерации. Контакт с заказчиком.

Итоги - все получилось. Сделали команду, платформу, сейчас - автономный полет.

Взялся - потому что вызов, интересно. "Настоящий самурай - не боится подвигов".

Остальные доклады

Эдвард Йордон (Nodruoy) Characteristics and policies of the best and worst IT organizations to work for

Увы, для начала - общие рассуждения. Что лучшее - люди понимают по-разному, что в кризис выбор ограничен. И что лучшие люди имеют больший выбор, чем средние. А потом - рассказ о прекрасном прошлом и его постепенном превращении в настоящее. С этого прошлого деньги превратились из мотивации в гигиенический фактор для большинства людей (в Штатах). И во всем мире число людей, для которых это так - выросло. И это хорошо. А тогда 3$ в час было счастьем.

Что такое хорошие места? Вклад в развитие - образование и тренинги. Свободное время для собственных проектов. И так далее. А плохие места не верят, что IT им важно и игнорируют. А еще они игнорируют или отвергают политику лучших мест. Вот на таком уровне, увы.

Девид Гарлан (Carnegie Mellon University) Software Architecture: Reflections on an Evolving Discipline

К сожалению, это тоже был доклад верхнего уровня с общими и дано известными идеями. В котором архитектура понималась как "набор верхнеуровневых схем", разнородные примеры которых демонстрировались без объяснений. А идеи и цели ее построения - тривиальны: декомпозиция, стандартная архитектура для интеграции, reusable, reduce cost. Последними словами в этой архитектуре являются SOA и Cloud. При этом реальные примеры ограничились SOA - dataflow и pipeline. Все. Увы, общие рассуждения из прошлого.

Николай Гребнев (CUSTIS) Психология управления: создание самоорганизующихся процессов

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

Андрей Вербицкий. Как создать продукт, которым будут пользоваться и любить?

Мы идем к массовому потребителю. И надо понимать, как создавать такие продукты. Это известно маркетингу, не неизвестно IT-шникам.

В начале доклада был рассказ об идеях Клейтона Кристенсена по книге "Стратегия жизни" (в соавторстве, вышла в 2012 на английском и в 2013 на русском).

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

Вопросы:

• Для какой работы наняли вещь
• Какую вещь наняли для этой задачи в прошлый раз.

Кейс milk shake. Разнообразно пытались увеличить продажи, меняя рецептуру - не получалось. Посмотрели покупателей. Оказывается, многие покупали утром, чтобы скрасить время до работы. И их совершенно не интересовала внутренность, важно - что унести с собой, 25 минут пить, без крошек. Заказчик поменял рецептуру, чтобы пили еще дольше - продажи увеличились.

Второй шаг. Принять, что используют люди. И надо учитывать их всякие психологические особенности. Человек с помощью продукта "выживает" - изменяет окружающий мир, чтобы сделать более удобной жизнь в нем. Упростить выбор, упростить понимание, снизить затраты на размышление. И надо понимать, для чего делаешь. 85% времени мозг работает по шаблону.

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

Александр Лесневский (Сбербанк Технологии) Что сильнее мотивации? По ту сторону сознания

Я слушал фрагментами, и они мне не слишком понравились. Потому что шли поверхностно-метафорические модели, типа "развивающий коучинг - это наездник на слоне", которые, к тому же, передавались на уровне умозрительного представления о реальности - докладчик на слоне не ездил :) Был здоровая модель зрелости эго Башкирова (записано со слайда, могу ошибаться). Визуально - как CMMI. Я думаю, польза та же :(

Была попытка разбора проблемы с 4 добровольцами - один рассказывает свою проблемы последовательно трем, а те пытаются спросить. Вывод был невнятный, потому что к третьему случаю рассказ стал более гладкий и более абстрактный, конкретика из него ушла. И что? Результат тривиальный...

Артем Кумпель (ITmozg) Кому лучше работается?

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