Является ли наличие керамического чайника непременным признаком говноменеджера? (6 вопросов).

Нет, это совершенно необязательно (например, если у птицы есть клюв – она же не обязательно дятел?). Для того, чтобы уверенно классифицировать объект как говноменеджера, требует систематическое следование им 2-3 или более изложенным в посте заповедям. А фарфоровые чайники – это внешнее, просто повод приглядеться к своему менеджеру получше.

Сегодня даже при мне 3 раза спросили про керамические чайники.

Похоже, что заметка Дениса ушла в народ. Да. 
Думаю, что на dev.by эта заметка произвела бы эффект разорвавшейся бомбы.

Лавра

Мое посещение конференции началось с неожиданной прогулки по Киевско-Печерской Лавре. Хорошая утренняя прогулка по памятнику зодчества охраняемого Юнеско. Да, это прекрасно.

«Лавра» на Яндекс.Фотках

Разве, что мороз ниже 20 градусов мешал наслаждаться архитектурой золотых куполов.

Agile Base Camp

«Твиттер-фид на конференции» на Яндекс.Фотках

К большому сожалению на конференцию не смог прибыть мой коллега Денис Петелин с докладом про выбор инструментов для Agile проекта. Оказалось, что данная тема крайне возбуждает умы проджект-менеджеров и разработчиков ближнего зарубежья. Вместо выбора тул-сета  я зачитал аудитории семинар о том, как управлять рисками в проекте. Это мой внутрениий тренинг в EPAM.

На мой взгляд риск-менеджмент относится к общей практике управления проектами и прекрасно ложится на agile-проекты. Безусловно там есть свои ньюансы. Риски waterfall проектов — это одна из приичин самого появления agile как методологии.

Этот семинар вызвал массу интереса со стороны… епамовских менеджеров. Уже поступили запросы на проведение внутренних вебинаров для agile-команд.

Coach Camp

«Coach Camp» на Яндекс.Фотках
Второй день. У меня сложилось такое ощущение, что не все из тех кто были на этом собрании являются (или планируют являться) agile-сенсеями. К сожалению, опоздал на знакомство. Но тем не менее в ходе наших обсуждений и разговоров я записал для себя много интересных моментов, которые надо прорабатывать вглубь.

Выяснять “что же такое Agile” не в моем вкусе. Подобные методологические споры лучше оставить профессионалам в методологиях. Нам же практикам лучше состредоточиться на том, как эти идеи двигать в массы. В частности, в наших компаниях и среди наших клиентов.

Для меня agile состоит из следующих составляющих:

• Философия.
  Как, зачем, почему в agile придумали работать именно так.
• Процессы.
  Конкретные процессы, которые надо ставить в компании + инстументы, позволяющие работать по agile.
• Знания + навыки.
  Набор знаний, которые надо донести до команды, которая думает использовать agile, а также навыки, которые надо помочь им развить.

По этим трем направлениям мне видится внедрение agile в компании от 30 человек. В более маленьких компаниях процессы никто не описывает, а выбор иструментов уже сейчас довольно широк (BaseCamp, AcuNote, JIRA…, не говоря уже про task-board и Excel).

Довольно часто я слышу про такие ситуации: люди попадают в какой-то странный процесс, рисование карточек, ежедневные отчеты, отсутствие какой-либо документации, а спустя пол года (опа!) узнают, что это был Скрам. Я могу допустить, что процессы в этом случае были поставлены верно и на уровне процесса там было нечто напоминающее Скрам, но без обучения сотрудников (знания + навыки) и без понимания почему это делается именно так (философия) такой процесс буксует самым страшным образом. Более того, сотрудники демотивируются попадая в такой проект.

Задумайтесь об этом, когда будете внедрять agile.

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

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

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

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

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

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

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

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

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

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

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

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

Вчера TUT.by представил миру свою новую стартовую страницу — http://new.tut.by/ . Заменить текущую главстраницу new должна с начала нового года.

Обсуждение стартовой страницы страны произошло в основном в твиттере: #newtutby, а вот на страницы блогов мнения пока толком никак не вылились. Или мнения измельчали, или формата твиттера уже достаточно, чтобы написать просто: АД, КАК ОН ЕСТЬ!

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

• Технический. Сверстать, запрограммировать, оптимизировать. Это десятки, а иногда и сотни человеко-часов.
• Учесть инертность пользователей. Пользователи не сразу принимают изменения, менять стартовую страницу кардинально никогда нельзя.
• Рекламный. Рекламодателям надо срочно показать, где и как будут располагаться новые рекламные площади. Рекламные агенства сооветсвенно должны уже начать предлагать и продавать новые рекламные площади клиентам.
• Маркетинговый…
• Аспект удобства…
• И т.п.

Ну собирается портал поменять стартовую страницу и что с того?
Но тут есть ньюанс. Тутбай являвется “визитной карточкой” страны, это ведущий портал Беларуси. Интернет деятели и разрабтчики всей краины следят за тем, как же выглядит эта “визитная карточка”. Предполагаю, что многие из тех, кто ругают тутбай, искренне хотят видеть его красивым и современным.

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

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

Для ребят и ТУТбая и Астронима, которые обижены тем, что их творческий порыв не находит хвалебных отзывов среди коллег-дизайнеров, есть отличные примеры порталов созданных нашими же белорусскими компаниями: Onliner.by, Oz.by, Lastochka.by (я уже не говорю про BFM.ru ). Визуально, юзабельно и технически они опережают ведущий портал страны на пару-тройку лет. До сих пор.

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

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

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

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

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

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

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

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

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

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

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

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

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

Гена Драгун, также будучи одним из докладчиков, высказал мнение, что “в Беларуси нет юзабилистов, есть только проектировщики”. Мне кажется, что дело обстоит несколько хуже. В Беларуси есть специалисты по проектированию пользовательских интерфейсов, но нет компаний, которые были бы заинтересованы в подобных мероприятиях. От того и конференция проходит в холодном зале, а не в гостинице Виктория. Зато вход свободный и всем рады.
Благо, что есть энтузиасты вроде Павла Коноплицкого, который в противовес всему продолжает заниматься организацией конференций.

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

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

Я жду когда с мероприятия появится видео. Кажется там что-то снимали.
А пока вот моя презентация:

Из нее мало, что понятно. Дождемся видео.

Search Engines ниже плинтуса. За месяц через поисковые машины судя по отчетам заходит всего около 40 пользователей. Для сравнения год назад этот показатель был равен 100.

Знающие и умные люди подскажите: может быть проблема в том, что поисковики выкинули мой сайт из индекса? И если так, то как его вернуть туда обратно?

Однажды, он рассказал мне, как он ездил на объект проверять сделанную монтажниками работу. Какого же было его разочарование, когда по совершенно точным чертежам, где сантиметр в сантиметр было прописано куда и какие розетки разводить и где делать отверстия в стене, было сделано все не правильно. У строителей-монтажников было свое мнение относительно того, где должна идти проводка и где должен писеть тот или иной щит.

Не смотря на то, что документация была очень подробна, не смотря на то, что эта документация являлась одним из артефактов, за которые платил заказчик — она не работала.

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

• Отсутствие обратной связи от рабочих с конструкторами, в виду чего документация устаревала и утрачивала свою ценность после проведения работ.
• Возможная неосведомленность конструкторов о реальном положении вещей в построенном здании. (”Нельзя здесь сверлить, понимаешь! Тут арматура…”)
• Личные предпочтения рабочих, которые считали, что так для них будет лучше, удобнее, проще сделать.
• Корыстное желание сэкономить провода и розетки, чтобы их потом украсть.

За преобладание личных предпочтений и желание украсть часть чужой собственности людей обычно увольняют, а вот первые два пункта это, как говорится, “наши недоработки”.

Что было бы если бы документации не было вообще? Ответ: Хаос! Бардак!

Представьте если вы решили просверлить стенку спустя 3 года после проведения работ и вместе с кирпичом просверлили 2 медных кабеля. Думаю, что после вы припомните родню ваших строителей до пятого колена…

{Я сторонник правильных аналогий относительно разработки программного обеспечения, поэтому опасаюсь метафоры “строительства здания”. Но думаю, что вы найдете зерно мысли в рассказанной мною истории.}

Зачем же я потратил ваше время, рассказывая эту историю? К чему я веду?

Все чаще мне приходится сталкиваться со следующим мнением: “Вы применяете agile? Да вы просто не умеете писать требования и аналитиков у вас нет!”  Я сам в прошлом аналитик, написал несколько десятков ТЗ и даже изложил ряд мыслей в известной статье про то, как надо писать ТЗ. А потом сам же дошел до жизни такой, когда сам же и внедрял agile в команде, которую собирал для одного из проектов.

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

Заглянем в сами принципы и ценности Agile:

• Принцип #3: Even late changes in requirements are welcomed
• Принцип #8: Continuous attention to technical excellence and good design
• И даже ценность: “Working software over comprehensive documentation” — не говорит о том, что документации не должно быть. Но мы смещаем фокус с идеальной документации на идеальное ПО.

Вот вам и ответы. Нигде не говорится про то, что документации быть не должно. Говорится о приоритетах. Те кто говорят, что документации не надо — пещерные люди.

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

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

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

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

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

Я почеркал в Evernote и набросал такую схему по уровням управления бюджетом:

• На уровне команды и менеджера проекта (PM) управление на уровне часов и дат сдачи проекта.
• На уровне координатора проектов/начальника отдела — внутренний бюджет и сроки сдачи всех проектов. На этом уровне часто идет совмещение с ресурсным менеджментом, поэтому на этом уровне также происходит управление затратами/себестоимостью.
• На уровне менеджера бизнес-юнита (BU) — реальные договора и реальные бюджеты + управление себестоимостью. Т.е. тут происходит управление рентабельностью.

Но часть себестоимости скрыта даже от BU менеджера. Это часть административных и транзакционных расходов, которые определяются финансовой службой и бухгалтерией на основании управления финансами не только центров доходов, но и центров затрат, таких как: IT, маркетинг, администрация и т.п. В этой схеме PM управляет деньгами только в случае совмещения ролей PM-координатора и менеджера BU. Грубо говоря, если менеджер BU сам является PMом.

Имея опыт работы, как BU менеджера, так и административного директора  я видел все необходимые движения средств. От перечисления денег на счет до выдачи зарплаты и уплаты налогов. И этот опыт дорогого стоит.

Пытливый и примечательный глаз заметит, что мой рассказ лишь немного отличался от того, что я рассказывал на конференции SoftwarePeople пол года назад.

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