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

Москву прет от нефте-долларов. Кругом стартапы, проекты, инвестиции. Позже вечером мы встречались с моим бывшим ведущим разработчиком, обсуждали эту движуху. Валик рассказывает, что поставил на HeadHanter’е заградительную зарплату, чтобы его не беспокоили рекрутеры… И чтобы вы думали? Они уже начали беспокоить. “Космическая” зарплата неожиданно стала реальной. При нехватке разработчиков зарплаты в Москве скоро будут выше, чем в Пало-альто. ;)

Дословная цитата: “Я сравниваю зарплату программистов и не ИТ-шников, я честно не знаю, как в Москве прожить непрограммисту.”

Как только аутсорсерам удается выживать в Москве?

Про мой доклад можно почитать здесь. Буду выступать в 17:15. Смотрите программу.

Также сегодня заехал в компанию Websoft, которая занимается разработкой LMS WebTutor. Часа 3 разговоривали с директором Алексеем Корольковым. Он показывал мне систему. Очень мощный продукт.

Компания тоже устроена грамотно: офис в Москве, разработчики в Казани, поддержка в Украине.  ;)

Чую приближение больших преобразований в нашей работе образовательных программ в EPAM. Продукт позволяет свести воедино все то, что разбросано у нас в 5ти системах. ;)  Проект внедрения по текущим ожиданиям примерно на год.

На прошлой неделе провели с коллегами первый в истории EPAM’а Mentoring Summit. Я почти уверен, что это название мало, что сказало вам. Поэтому поясню подробно.

Менторинг

Менторинг программы (или программы наставничества) это длительные образовательные программы, которые мы уже несколько лет запускаем в компании по нескольким направлениям. Коротко суть:

• Длительность программ 6-9 месяцев.
  
• Обучение происходит в группах 2-4 человека. У каждой группы есть наставник.
  
• Обучение имеет производственный вектор: читаются лекции и выполняются задания на проекте.
  
• На выходе готовый специалист уровня D3/T3 (Senior).
  

По отдельным направлениям программы длятся уже по 3 года. За это время некоторые менти (обучающийся в менторинг программе) выросли в менторов, а некоторые менторы выпустили по 3 группы специалистов. И вот сидели мы как-то осенью прошлого года с куратором менторинг программы по тестированию и думали: как бы нам собрать всех менторов вместе и обменяться опытом. Задумали “междусобойчик” для минских ребят, а вылилось это в целое международное событие.

Мероприятие

Итог: 18 марта в стенах ПВТ прошел первый в истории компании Mentoring Summit – внутреннее мероприятие, на которое мы свезли текущих и будущих кураторов, менторов и тренеров с 8-ми локацией EPAM’а из 4х стран. Перед организацией мероприятия я поставил две цели:

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

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

Специально под мероприятие я организовал разработку стилистики образовательных программ, а также самого мероприятия. Мне кажется, что неплохо получилось. ;)

Доклад

Наши коллеги рассказывали о том, как у них двигаются и развиваются программы в своих локациях. Я рассказывал о том, как программы запускать.

Юрий Шиляев рассказывает, как взлетают образовательные программы в EPAM. :)

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

Но думаю, что часть информации расскажу на конференции SoftwarePeople в Москве 7-8 апреля.

Итоги

Уже сейчас очевидно, что мероприятие подарило нашей команде несколько проектов:

• Запуск ряда образовательных программ в нескольких городах Беларуси и России.
  
• Создание внутреннего менторского сообщества Mentoring Club.
  
• И соответственно создание сайта для него.
  

Знаете, я поражен КПИ. Это настоящий кампус с корпусами 19-го века, с огромным парком и площадкой, где проводятся концерты. Рядом расположены общежития. В Минске, к сожалению, нет ничего похожего. Да, у БГУ есть небольшой дворик, у БГУИР есть какая-то территория, но ощущения университетского пространства там нет.

Альбом: Abrakadabra

Я прочитал для студентов 2 лекции:

• IT: Кем ты можешь быть?
• Компетенции XXI века. Практика корпоративного обучения.

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

Презентацию второй лекции обещал выложить. Держу обещание:

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

Коллеги в свою очередь рассказывают про UML, процесс разработки ПО, завтра будут рассказывать про Java и тестирование. Думаю, что для студентов это очень полезные лекции.

Существуют несколько принципов работы лифтов, которые я заметил и выделил. Очевидно, что лифты в высоких зданиях и низких работают несколько по-разному, в административных и жилых тоже есть разница. Например, в жилых основной сценарий перемещения: с 1го этажа на n-ый и с n-го на 1й. Поэтому нет кнопок вверх-вниз, есть только одна кнопка вызова лифта. В офисных наоборот, кнопки две, потому что добавляется перемещение с этажа на этаж в произвольном порядке.  Если здание высокое, то есть возможность подхватывать людей едущих вниз. И т.д.

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

Хорошо, а теперь представим, что в нашей команде есть человек, который всегда работал только с жилыми зданиями. Назовем его Грег. Грег свято верит в систему “1-n, n-1″ — она идеальна, проста и понятна всем. Каждый кто говорит, что это не так — ничего не понимает в жизни и лифтах. Все остальные системы — сложные пережитки прошлого. Грег — евангелист простой системы управления лифтами.

Евангелизм, вера в какие-то методы работы и подходы — это круто, классно. Но без системного понимания почему тот или иной метод и подход работает весь евангелизм теряет смысл. Вы можете отказаться от какой-либо документации между командами, даже если они распределенные (“Больше коммуницируйте, ребята!”). Вы можете внедрять ужасно навернутый процессный тул для мега-джедаев, которые сидят в одной комнате. Или вы можете вообще не учитывать никаких рисков, веря в “лучшее” или в составленный контракт.

Но еще круче, если мы не изучим ни одной системы управления лифтами (или командами). А выдадим менеджеру короткий емкий тренинг мастерски умещенный в двух словах: Good Luck! Ведь что для менеджера главное? Заряд оптимизма! Петарда в ж…! Зачем ему знать системы управления проектами, модели построения команд, методы рассчета и учета рисков, схемы планирования, методы мониторинга и контроля, GTD?

Важно только не терять вместе с ним надежды, что он всему этому научится сам! За ваши деньги.

Во второй день читал мастер-класс про управление рисками в проектах. Забавное дело, в воскресенье встал рано утром, бытро собрался и чуть было не приехал на мероприятие на час раньше. Вспомнил об этом уже на пол пути в машине, остановился и набросал в лэптопе небольшой mind map по рискам, которые могут произойти со стартапом. План был такой: презентации нет, поэтому разберу вместе со слушателями риски, которые могут произойти с их новым проектом. Приехал, пообщался с участниками… и понял, что если рассказать им все риски, которые с ними могут произойти — порбосают любые начала. :)  Пришлось подготовить презентацию за 20 минут (как настоящий джедай), благо материал уже был.

Зачитал основы риск менеджмента, а составленный mind map пообещал выложить тут, на сайте.

Держу обещание, поэтому файл тоже можно забрать от сюда: startup_risks.mmap.

Завтра, в пятницу 9го апреля выступаю с небольшим мастер-классом по “Исскуству презентаций”. В рамках подготовки проекта Minsk StartUp Weekend. Надеемся, что два мастер-класса и неделя подготовки помогут участникам достойно подготовиться к данному мероприятию.

Некоторые темы выступления согласовываются, но в кратце:

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

Об условиях участия в мастер-классах написано как на официальном сайте мероприятия, так и на нашем сайте Agile.by.

До встречи!

Сама по себе самоорганизованность вещь безусловно полезная и крайне важная. Но вот в чем вопрос: на одинаковых ли принципах строится самоорганизованность менеджера и сотрудника?

И вот тут есть маааленький ньюанс. О котором можно было бы не упоминать… Подчиненные != менджеры. Кто они? Очень часто это программисты и тестировщики. Язык не поворачивается назвать их рабочими, поэтому для простоты назовем их Worker’ами.

Посмотреть на Яндекс.Фотках

Какая разница между этими двумя типами?

У них разный ритм работы (а часто и жизни).

Рабочий день Manager’a наполнен встречами, звонками, поездками, ответами на важные письма, коммуникациями в разных видах. Вот как выглядит календарь типичного менеджера:

Посмотреть на Яндекс.Фотках

День менеджера делится на четкие кусочки времени по 30-60 минут, о которых он говорит так: “Привет, Паша, у меня в среду после обеда будет дырка в расписании, можем заделать колл в это время.” Все задачи менеджеры делят по типам “что” и “когда”, настраивают себе ремайндеры, покупают телефоны с поддержкой календаря и списка задач, синхронизируют его со своим Outlook’ом.

Рабочая неделя Worker’а выглядит несколько иначе… Примерно вот так:

Посмотреть на Яндекс.Фотках

Весь рабочий день worker’a можно разделить на 2 части:

• ДО обеда.
• ПОСЛЕ обеда.

Все. Нет никаких окошек, нет никаких коротких отрезков. Ритм разработчика — сидеть и делать задачу, думать, в башке крутить, искать информацию, советоваться с коллегами. До тех пор пока не поборет. Смена контекста для worker’a происходит медленно, а входить в новый контекст надо с усилием. Менеджерами как раз и становятся те, кто способен много коммуницировать и быстро менять контекст.

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

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

Выводы тут простые:

• Чем меньше отвлечений, тем лучше разработчик входит в “поток”.
• Планировать совещания и мероприятия лучше ближе к обеденному перерыву или концу рабочего дня. Можно начинать день со стендап-митинга.
• Если митинг на 2 часа запланирован где-то “после обеда”, часть дня “ПОСЛЕ обеда” для разработчика будет потеряна.
• Учить личной эффективности worker’ов надо в ключе ритма их работы. Time management для менеджеров и разработчиков отличается.

Например вы написали программу, протестировали приложение, прочитали семинар или  приготовили макароны. Как вы определите, что достигли желаемого результата?

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

Если не вдаваться в сложные рассуждения на тему абстракций, то у нас мало  первоначальных метрик для оценки подобных заданий. Главное о чем мы можем  спросить себя: “Доволен ли тот, ради кого мы старались?”. Если этот кто-то ваш  начальник — вам продложают платить зарплату, если партнер, то продолжается работа по  контракту и проект развивается.

Следующий шаг — ответить на вопрос: “Что делает его довольным?” Ответы могут быть  такими:

• 80% фич по проекту поставляется во время.
• Рентабельность проекта держится на уровне 20%.
• Знания в компании накапливаются.
• Текучесть кадров снижается на X%.
• И т.п.

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

Часто мы не имеем первого и последнего этапа этой цепочки. Если изначальная цель не сформулирована — задачи формулируются исходя из каких-то личных представлений о цели, которую мы “вроде бы достигаем”. В этом случае наступает то, что я называю “вакуум целей”: отсутствие базиса для принятие решений. Простейший пример вакуума целей — ориентированность на бюджет. Если мы формулируем цель проекта, как “рентабельность не ниже….”, то так или иначе в процессе реализации проекта мы сталкиваемся с необходимостью принимать решения о качестве проекта, о мотивации проектной команды и наша единственная изначальна я цель либо не дает ответа, не задает базиса для принятия решений, либо (что хуже) заставляет принимать решения во вред проекта.

Вот здесь мы можем сформулировать еще одно важное утверждение. Формулирование целей решает две задачи:

1. Задает базис для принятия решений и формулировании задач.
2. Позволяет валидировать и верифициаровать результат. Т.е. по сути принять еще одно решение — цель достигнута.

Если говорить о процессе разработки проектов, то целями в этом случае являются фичи, которые разрабатываются и поставляются клиенту. В этом случае:

• Цель – фича, набор фич, итерация.
• Задача – задачи по разрботке, документированию, внедрению, поставке ПО.
• Валидация/верификация задачи — тестирование, тестовые сценарии и т.п.
• Валидация/верификация цели — Definition of DONE.

Цель — это и метрика и отправная точка.

Self process или процесс самоуправления — это личный процесс человека в его работе. Будь он разработчик или тестировщик, не говоря уже про менеджера — каждый сотрудник должен уметь управлять собой, своими задачами и в конечном счете целями.

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

В качесте демонстраци простоты инструментов управления собой я однажды нарисовал свой собственный таск-борд:

Это простой лист ватмана формата А3, который я разлиновал маркером за минуту. Сначала продумал что мне надо от этого таск-борда, сделал пару придок в блокноте, а потом разрисовал лист.

Все задачи в листе делятся на 3 временные характеристики:

• Сегодня;
• На неделе;
• Длинные задачи или задачи, которые должны быть отложены до будущего.

Всего есть 4 состояния у задач:

• ToDo – своеобразный беклог.
• Progress – то что делается.
• Check — проверка.
• Complete – закончено.

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

Как проходил процесс работы с этим таск-бордом:

• В понедельник я планировал неделю, записывая задачи на стикерах и расклеивая на конкретные даты недели.
• Каждый день я проводил пересмотр задач и довешивал дополнительные в раздел Today.
• Когда я брался за какую-то задачу, то перевешивал ее в Progress. После в Check и когда сам удостоверялся, что задача закончена в Complete.
• Если появлялись задачи, которые не надо было решать на этой неделе — они вешались в Long.
• В конце недели все задачи из Complete – выкидывались.

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

Тем не менее, техникой я был очень доволен. Если кому будет интересно — берите на вооружение.