KEA20 - Кирилл Копылов - Внедрение канбана в сервисной компанииRealResult
В докладе кратко изложена история использования Канбан Метода в фирме далекой от IT-контекста настолько, насколько это можно себе представить. Имея идентичность "посуточной компании", мы "начали встречаться у доски" 20 месяцев назад. Наш коллектив оказал сопротивление и форме и сути Канбан Метода.
Я расскажу историю о сопротивлении, формах противостояния и способах его трансформации. Будут показаны проблемы, которые замедлили наше движение и которые мы создали себе сами, совершая как теперь видно, типичные ошибки на пути внедрения 6 практик метода.
Будут перечислены положительные эффекты, которые мы связываем с двухлетним использованием принципов управления изменениями Канбан Метода и визуального управления в организации максимально далекой от производства программного обеспечения.
Вы помните, как вы представляли себе Канбан, когда первый раз о нем услышали? Я помню. И с тех пор мое мнение о методе менялось, и не один раз, помогая найти новые пути для совершенствования сервисов в компании, в которой я работаю. В докладе я расскажу о своих наблюдениях глазами тренера и коуча, как меняются со временем взгляды команд на инструмент и какие новые возможности они для себя открывают
В книжках мы читаем красочные описания того, как здорово живется в мире agile. Как все делается вовремя, никто не отвлекает от интересной работы, никто не требует на скорую руку воздвигнуть пирамиду Хеопса с костылями в качестве основного строительного материала.
На тренингах нам даже удается попробовать и поверить в то, что все это работает и достижимо в рамках отдельно взятой реальности. А потом мы возвращаемся на свои рабочие места и... Ну, вы и сами прекрасно знаете, как оно бывает потом.
Внедрение Agile - это не просто изменение процессов. Это - изменение культуры. Это - новая глава в истории компании. Это - изменение отношения к бизнесу. И многие из вас были свидетелями колоссального сопротивления и напряжения, сопутствующего этим изменениям.
Не важно, кто вы при этом - CEO, технический директор, Agile-коуч. Высокое сопротивление и колоссальное напряжение - это ваша среда. И вы в этой среде - Трансформатор. Как быть Трансформатором? Какие знания, умения и навыки позволяют совершать изменения? Мешают ли сопротивление и напряжение на самом деле? Как не перегореть в этом поле?
Dmytro Lukianov: Вплив емоціїного інтелекту на прийняття рішень в управлінні ...Lviv Startup Club
Dmytro Lukianov: Вплив емоціїного інтелекту на прийняття рішень в управлінні проектами
Website - https://pmday.org/online
Fb Page - https://www.facebook.com/pmdayconference
PMDay Videos -https://www.youtube.com/user/StartupLviv/featured
KEA20 - Кирилл Копылов - Внедрение канбана в сервисной компанииRealResult
В докладе кратко изложена история использования Канбан Метода в фирме далекой от IT-контекста настолько, насколько это можно себе представить. Имея идентичность "посуточной компании", мы "начали встречаться у доски" 20 месяцев назад. Наш коллектив оказал сопротивление и форме и сути Канбан Метода.
Я расскажу историю о сопротивлении, формах противостояния и способах его трансформации. Будут показаны проблемы, которые замедлили наше движение и которые мы создали себе сами, совершая как теперь видно, типичные ошибки на пути внедрения 6 практик метода.
Будут перечислены положительные эффекты, которые мы связываем с двухлетним использованием принципов управления изменениями Канбан Метода и визуального управления в организации максимально далекой от производства программного обеспечения.
Вы помните, как вы представляли себе Канбан, когда первый раз о нем услышали? Я помню. И с тех пор мое мнение о методе менялось, и не один раз, помогая найти новые пути для совершенствования сервисов в компании, в которой я работаю. В докладе я расскажу о своих наблюдениях глазами тренера и коуча, как меняются со временем взгляды команд на инструмент и какие новые возможности они для себя открывают
В книжках мы читаем красочные описания того, как здорово живется в мире agile. Как все делается вовремя, никто не отвлекает от интересной работы, никто не требует на скорую руку воздвигнуть пирамиду Хеопса с костылями в качестве основного строительного материала.
На тренингах нам даже удается попробовать и поверить в то, что все это работает и достижимо в рамках отдельно взятой реальности. А потом мы возвращаемся на свои рабочие места и... Ну, вы и сами прекрасно знаете, как оно бывает потом.
Внедрение Agile - это не просто изменение процессов. Это - изменение культуры. Это - новая глава в истории компании. Это - изменение отношения к бизнесу. И многие из вас были свидетелями колоссального сопротивления и напряжения, сопутствующего этим изменениям.
Не важно, кто вы при этом - CEO, технический директор, Agile-коуч. Высокое сопротивление и колоссальное напряжение - это ваша среда. И вы в этой среде - Трансформатор. Как быть Трансформатором? Какие знания, умения и навыки позволяют совершать изменения? Мешают ли сопротивление и напряжение на самом деле? Как не перегореть в этом поле?
Dmytro Lukianov: Вплив емоціїного інтелекту на прийняття рішень в управлінні ...Lviv Startup Club
Dmytro Lukianov: Вплив емоціїного інтелекту на прийняття рішень в управлінні проектами
Website - https://pmday.org/online
Fb Page - https://www.facebook.com/pmdayconference
PMDay Videos -https://www.youtube.com/user/StartupLviv/featured
Продуктовая Аналитика — Карго Культ в современных компанияхEvgeny Kuryshev
В условиях быстрой разработки становится более важным и более сложным такой вопрос: если мы можем менять вектор развития продукта очень часто и умеем жить с изменяющимися требованиями, то как понять что мы рационально используем эту возможность, не прыгаем вперёд-назад, а остаемся сфокусированными в своём развитии продукта?
Тут, разумеется, есть куча инструментов и практик lean практики get out of the building, традиционная продуктовая аналитика и, конечно, всеми любимые A/B тесты.
Но многие бросившись использовать всё это внезапно понимают, что получившиеся процессы больше напоминают карго культы: A/B тестирование красных против зеленых кнопок на страницах где 100 человек в день с конверсией в 5% делают какой-то экшн. Или обвешивание счётчиками Google Analytics всех элементов интерфейса, который используют 3 человека в день. Или мы идем в гости к своим друзьям, чтобы узнать их мнение о новом дизайне, забывая о том что наши друзья совсем не репрезентативны.
С какими проблемами мы сталкивались, как мы разочаровались в этих практиках, успели их возненавидеть и как обратно поверили и полюбили эти и другие подходы развития и эволюции продук
Тактическое управление продуктами: все еще недостающее звеноMaxim Gaponov
«Эти люди делают то, о чем я их прошу. Но в результате каждый раз получается не то, что мне нужно». Эта фраза, в той или иной форме, произносится каждым клиентом, с которым я работаю.
«У нас было все, что нужно. Требования, выборки, прототипы. В итоге не успели сделать и половину. А то, что сделали нежизнеспособно» — такое тоже встречается часто.
На каждой стратегической сессии выясняется, что реальный объем работ, которые необходимо совершить, в 4-5 раз превышает тот, который запланирован. И, что самое интересное, этот объем озвучивают сами участники, которые и являются авторами предыдущих нереалистичных планов.
Слушайте, с этим пора что-то делать :) Это же не магия какая-нибудь. Это ремесло. Ремесло о том, как системно сформировать и договориться о границах работ; ремесло, как закрепить за ролями ответственность; ремесло, как выстроить управление и коммуникации между разными уровнями доставки бизнес-ценности; ремесло, как оценивать текущую зрелость процессов и обеспечивать непрерывное улучшение.
В докладе я расскажу вам о своем опыте решения этих задач в разных компаниях.
Как UX/UI дизайнеру работать в команде? Выстраивание дизайн-процессаNetpeak
Презентация доклада с Netpeak Talks №5 в Харькове
Докладчики: Татьяна Гуменюк (Web designer for special projects at Netpeak) и Анна Даценко (Head of design at IdeaSoft Group).
30 мая, Харьков
Екатерина Типанова (QA engineer / I-Free) выступила на семинаре "Как стать TRUE-тестировщиком #3" от учебного центра Урансофт, и рассказала о жизненном цикле тестировщика.
Основа успеха любой организации - в ее умении следовать и развивать свои уникальные особенности и ценности. 10 заповедей Тайти Оно и 14 принципов Тойота, описанных Лайкером, это и есть уникальный набор свойств компании Тойота.
Презентация восьмого занятия факультива "Предпринимательский образ мышления" в НИУ ВШЭ.
Онлайн площадка для обсуждения и выполнения Home Work http://vk.com/ideann
Продуктовая Аналитика — Карго Культ в современных компанияхEvgeny Kuryshev
В условиях быстрой разработки становится более важным и более сложным такой вопрос: если мы можем менять вектор развития продукта очень часто и умеем жить с изменяющимися требованиями, то как понять что мы рационально используем эту возможность, не прыгаем вперёд-назад, а остаемся сфокусированными в своём развитии продукта?
Тут, разумеется, есть куча инструментов и практик lean практики get out of the building, традиционная продуктовая аналитика и, конечно, всеми любимые A/B тесты.
Но многие бросившись использовать всё это внезапно понимают, что получившиеся процессы больше напоминают карго культы: A/B тестирование красных против зеленых кнопок на страницах где 100 человек в день с конверсией в 5% делают какой-то экшн. Или обвешивание счётчиками Google Analytics всех элементов интерфейса, который используют 3 человека в день. Или мы идем в гости к своим друзьям, чтобы узнать их мнение о новом дизайне, забывая о том что наши друзья совсем не репрезентативны.
С какими проблемами мы сталкивались, как мы разочаровались в этих практиках, успели их возненавидеть и как обратно поверили и полюбили эти и другие подходы развития и эволюции продук
Тактическое управление продуктами: все еще недостающее звеноMaxim Gaponov
«Эти люди делают то, о чем я их прошу. Но в результате каждый раз получается не то, что мне нужно». Эта фраза, в той или иной форме, произносится каждым клиентом, с которым я работаю.
«У нас было все, что нужно. Требования, выборки, прототипы. В итоге не успели сделать и половину. А то, что сделали нежизнеспособно» — такое тоже встречается часто.
На каждой стратегической сессии выясняется, что реальный объем работ, которые необходимо совершить, в 4-5 раз превышает тот, который запланирован. И, что самое интересное, этот объем озвучивают сами участники, которые и являются авторами предыдущих нереалистичных планов.
Слушайте, с этим пора что-то делать :) Это же не магия какая-нибудь. Это ремесло. Ремесло о том, как системно сформировать и договориться о границах работ; ремесло, как закрепить за ролями ответственность; ремесло, как выстроить управление и коммуникации между разными уровнями доставки бизнес-ценности; ремесло, как оценивать текущую зрелость процессов и обеспечивать непрерывное улучшение.
В докладе я расскажу вам о своем опыте решения этих задач в разных компаниях.
Как UX/UI дизайнеру работать в команде? Выстраивание дизайн-процессаNetpeak
Презентация доклада с Netpeak Talks №5 в Харькове
Докладчики: Татьяна Гуменюк (Web designer for special projects at Netpeak) и Анна Даценко (Head of design at IdeaSoft Group).
30 мая, Харьков
Екатерина Типанова (QA engineer / I-Free) выступила на семинаре "Как стать TRUE-тестировщиком #3" от учебного центра Урансофт, и рассказала о жизненном цикле тестировщика.
Основа успеха любой организации - в ее умении следовать и развивать свои уникальные особенности и ценности. 10 заповедей Тайти Оно и 14 принципов Тойота, описанных Лайкером, это и есть уникальный набор свойств компании Тойота.
Презентация восьмого занятия факультива "Предпринимательский образ мышления" в НИУ ВШЭ.
Онлайн площадка для обсуждения и выполнения Home Work http://vk.com/ideann
Догнать и перегнать: российский и западный опыт применения качественных метод...Собака Павлова
28 октября 2016 года, SECR, Москва.
http://2016.secr.ru/program/submitted-presentations/russian-and-foreign-experience-of-usage-qualitative-methods-in-ux-research
На Западе вот уже 30 лет изучают феномен производственной системы компании Toyota, но ни одной компании так и не удалось повторить успех Toyota. У нас есть все шансы сделать это, поняв, что нам не надо копировать принципы и методы работы Toyota, а надо самим заниматься развитием своей собственной производственной системы, используя, конечно, опыт Toyota и других компаний. Как сделала, например, компания ТехноНИКОЛЬ. Если получилось у них, получится и у нас!
«Какие компетенции нужны вашим сотрудникам? Начинаем разработку модели компетенций», Алексей Широкопояс , главный редактор журнала «Компетенции»
«Что-же в итоге лучше? Говорим об идеальных тренинговых подходах», Юстус Генрих, T&D специалист, компания LTC
Кейс компании «Любимый край» — лидера российского рынка овсяного печенья, «Как на базе внутреннего обучения создавался внешний образовательный продукт», спикер конференции «Корпоративное Обучение»(апрель 2014) , директор по управлению знаниями КО «Любимый Край» Наталья Бутомо.
«Хроника современности - борьба с киберпреступностью против креативного ликбеза. Бизнес-симуляция для «Лаборатории Касперского», Олег Замышляев, «Мастерская Олега Замышляева»
«Ошибки делегирования», Арина Гороховская, руководитель проекта RESPONSING
«HR-бренд как конкурентное преимущество. Социальные сети - это отличный канал дистрибуции HR-бренда», примеры, как известные компании продвигают свой HR-бренд на Viadeo. , Меланя Айдинян, Viadeo
«Как сделать карьеру за рубежом» Разберем по-шагам. Серия публикаций», Ольга Лапшина, рекрутер фармацевтической компании Bayer
«Насколько привлекательна для выпускников перспектива переезда за границу с целью трудоустройства» Опрос Career.ru
Менеджерские школы учат, как готовить проекты правильно. А реальность говорит про 30% успешного завершения проектов. Чувствуете проблему?
Этот доклад про опыт. Про множество подходов, которые смогут помочь ускорить разработку. Никакой уличной магии нет, есть множество рецептов, приводящих к результату, который даёт на выходе работающий продукт и радует заказчика. Это факторы планирования, технологий, психологии, презентации, приоритезации и многие другие.
Приготовьтесь к изменениям!
Самурай оптимизации: как отличить эффектность от эффективности?Sergey Chadin
Материалы к вебинару по эффективным приёмам оптимизации издержек, проведённому 04.04.14 в редакции журнала "Финансовый директор" (Москва).
Запись вебинара доступна на YouTube www.youtube.com/watch?v=7pYgm_MyWPA#t=373
«Profiles International Ukraine» делится мнением с журналом "Компа&ньон"
В свежем номере журнала "Компа&ньон" управляющий партнёр "Profiles International" Олег Афанасьев рассказал о том, как устаревшая система оценки персонала, тормозит движение компании к продуктивной деятельности.
В статье раскрывается новая эффективная схема модели организации бизнеса, а также даются секреты, как действовать результативно.
Интервью можно прочитать на странице: http://www.companion.ua/articles/content?id=210196
Сколько стоит ерунда, или как инвестировать в качество сайта
Качество продукта через управление проектом
1. Ольга Павлова
www.pavlova.cc
Качество продукта через
управление проектом: что
конкретно делать менеджеру?
Рассмотрим немножко теории — и даже теорий — про качество продуктов и
процессов. Поймём, почему они не имеют никакого отношения к нашей суровой
действительности. Поймаем себя на умолчаниях, душащих качество, и подумаем,
как избавиться от этих вредных привычек. Обсудим, как и что нужно делать на
каждом этапе проекта, чтобы дальше не было мучительно больно. Выявим в
команде борцов за качество и отличим их от недовольных нытиков. Да, и не
скажем, наверное, ни слова о тестировании релизов.
Немного теории для сомневающихся
Раз вы задались вопросом «Как сделать хорошо?» — значит, у вас есть как
минимум один ответ на вопрос «Как, собственно, вообще сделать?». И обычно этот
ответ материализуется как смесь управленческих теорий, жизненного опыта и
волшебных заклинаний.
Опыт и заклинания оставим на сладкое, а сейчас — о самом простом: о теориях.
Давайте сначала инвентаризуем теории, претендующие на управление качеством:
1. Всеобщее управление качеством (TQM). Главная идея: нужно повышать не
только качество продукции, но и качество производственных процессов.
Основной инструмент: развитие персонала, минимизация количественных
показателей и принятие всех решений с ориентацией на качество процесса и
результата.
2. Шесть сигм. Главная идея: нужно минимизировать брак на каждом этапе
производства через уменьшение статистических отклонений ключевых
параметров производственных процессов. Основной инструмент: сквозное и
непрерывное измерение всего, что можно измерить, и поощрение инициатив,
уменьшающих вероятность и величину отклонений от нормы.
http://www.pavlova.cc Страница 1
2. 3. Бережливое производство. Главная идея: нужно минимизировать
производственные потери (деятельность, потребляющую ресурсы, но не
создающую потребительской ценности). Основной инструмент: плавные
производственные процессы без перепроизводства (система «точно вовремя»).
4. Теория ограничений (TOC). Главная идея: нужно повышать скорость генерации
прибыли и уменьшать связанный капитал через подчинение темпа всех
производственных процессов возможностям самого узкого места системы.
Основной инструмент: установление прямой связи локальных показателей
эффективности с двумя глобальными (скорость генерации прибыли и связанный
капитал).
5. Ассоциированная система менеджмента качества. Главная идея: сюрприз-
сюрприз, научно-техническую деятельность тоже можно стандартизировать на
макроуровне. Основной инструмент: стандарт ISO 9000.
Много букв, правда? На самом деле не то чтобы это важные буквы. Вы можете
легко их проигнорировать. Просто вдруг вам для подтверждения собственной
интуиции нужны красивые слова и авторитетные имена — а тут вот, пожалуйста, и
то, и другое в ассортименте, наслаждайтесь.
Особо интересно поискать противоречия между всеми этими заслуженными и
популярными системами. Самых очевидных два:
1. «Всеобщее управление качеством» минимизирует использование
количественных показателей, а «Шесть сигм» — полностью на них опирается.
2. «Теория ограничений» борется с локальными показателями эффективности, а
для «Шести сигм» они жизненно необходимы.
Да, вы правы, автор недолюбливает «Шесть сигм» — но причиной тому весьма
субъективный жизненный опыт. Так или иначе, теории действительно друг другу
противоречат, и при внедрении всё равно придётся думать своей головой.
Вернёмся к нашему желанию найти ответ на вопрос «Как сделать хорошо?» в
конкретном случае конкретной компании. Кажется, что ответ должен быть
развитием ответа на вопрос «Как сделать?». То есть, например, если вы работаете
по Scrum, но результат получается «на троечку», то нужно магически улучшить
Scrum с помощью, например, «Теории ограничений» — и «троечка» превратится в
«пятёрку с плюсом».
На самом же деле связи между этими ответами нет. То есть когда мы начинаем
говорить о качестве, перед нами появляется просто другой класс управленческих
задач, никак не соотносящийся со «сделать вообще». И поэтому эволюции, скорее
всего, не случится: чтобы сделать хорошо, привычные методы и практики придётся
подчинять новым схемам, и это безболезненно не пройдёт.
http://www.pavlova.cc Страница 2
3. Качество — объект управления
Переформулирую мысль предыдущего абзаца: какая бы производственная
культура ни сложилась в вашей компании, повышение её качества — сложная
управленческая задача.
Остановлюсь подробней на этой неприятности. Мы привыкли, что
производственный процесс устраивается как-то сам собой. Ну правда, достаточно
определить цель и упорно к ней идти, чтобы рано или поздно, так или иначе — таки
дойти. Героическими авралами, силой интеллекта лидеров разработки, харизмой
менеджеров и вливаниями инвесторов — так или иначе проекты обычно доживают
до технического запуска.
Поэтому о том, как идёт проект, особо никто не задумывается. Ну, у кого-то иногда
случается внезапное озарение и часть проектных работ формализуется,
регламентируется и шаблонизируется. Обычно такие формализованные процессы
быстро умирают за ненадобностью, особенно на небольших проектах. Лучшая тому
иллюстрация — тотальное нежелание всех участников рабочей группы всерьёз
планировать работы и придерживаться плана проекта.
Проект закончен, языки у всех на плече, «мы пахали», мы герои, победителей не
судят. В следующий раз идём примерно так же — тропинка уже протоптана. И в
следующий, и в следующий… Так складывается производственная культура.
Итак, доминирует аврально-героический метод формирования производственной
культуры. А теперь подумайте — можно ли таким методом улучшить качество?
Качество продуктов, производственных процессов, информационного обмена,
маркетинговой поддержки и т.д.? Если компания создана по принципу «Бросили в
воду — и плыви», то пловцам уже не до красивого стиля: им бы не захлебнуться и
добраться до берега. Не скажу, что все компании такие, но IT — подавляющее
большинство.
Что ж, мы поняли, что улучшения качества снизу — не будет. А значит, придётся
улучшать сверху.
Мамочки, куда я попал?
Улучшать сверху — это не значит, что мы садимся ровно и ждём сигналов от
начальства. Но это значит, что менеджер выбирает систему управления качеством
— и ставит внедрение этой системы выше своих хотелок.
Иначе говоря, первый шаг менеджера к качеству: нужно для себя решить, что
система управления качеством важнее авральной самореализации и «ориентации
на результат».
Результат, повторюсь, и без менеджера никуда не денется. Так уж в IT заведено,
что люди в подавляющем большинстве действительно хотят добиться результата и
сделать свою работу. Убить это желание и развалить проект ещё до технического
http://www.pavlova.cc Страница 3
4. запуска — надо здорово постараться, умельцы редки и ценятся на вес акций
Facebook'а.
Таким образом, дело менеджера — внедрять систему управления качеством.
Здорово повезло, если эту задачу хоть как-то поддерживает начальство. Лучше
всего, если у этого начальства есть своё видение идеала, отличное от «Хочу, чтобы
было, как у Apple/Google/Volvo». Тогда дальше можете не читать — выясняйте, что
это за видение, и работайте над воплощением :)
Вторая по степени везения ситуация — когда уровень производственной культуры
в компании держится на нескольких перфекционистах. Каждый из них в
отдельности может легко свести с ума нетерпеливого и поверхностного
менеджера. Но в целом они транслируют в пространство — и наглядно
демонстрируют в работе — простой принцип: работать надо хорошо. С плеч
менеджера благодаря этим людям падает безумная пропагандистская задача:
доказывать, что тема качества вообще достойна внимания. Перфекционисты-
разработчики борются с халтурщиками своими методами (о которых лучше нежным
управленцам не знать) — прям санитары леса, носите их на руках. Платить за это
счастье придётся подстройкой своих управленческих воздействий под ценных
перфекционистов. Впрочем, это того стоит.
Но обычно менеджер остаётся с проблемой один на один. Нужно, чтобы было
хорошо, но как — решай сам, дорогой. А пока ты решаешь, мы будем работать, как
привыкли: кто-то хорошо, кто-то спустя рукава. Нормальная ситуация в российских
реалиях с их слабой методической культурой и высоким уровнем пресловутой
«ориентации на результат».
А что делать, что делать-то?
Вариантов внедрения системы управления качеством, по большому счёту, два:
эволюционный и революционный.
Революционный — проще некуда: составляем себе стройную схему «Как я буду
контролировать и повышать качество», согласовываем с начальством и внедряем.
Проще всего взять какую-нибудь из вышеперечисленных теорий, слегка
адаптировать под IT и дальше придерживаться её с упорством школьника, вчера
прочитавшего про ООП. Не работает, но весело и все при деле.
Эволюционный, на мой взгляд, несколько эффективней:
1. Вытаскиваем из теорий и практик все принципы и рекомендации по повышению
качества, в которые вы — лично вы — верите.
2. Выбираем какую-нибудь практику, которую можно применить здесь и сейчас.
3. Практикуем в безопасном месте и смотрим, что получилось.
4. Если выглядит убедительно — внедряем конкретно эту практику повсеместно.
http://www.pavlova.cc Страница 4
5. 5. Выбираем следующую практику — и далее по циклу.
Самое сложное здесь, конечно, в том, что за эволюционным методом не стоит
никаких авторитетов и никакого опыта. Всё будет происходить на ваш страх и
риск. Фактически вы строите карточный домик на фундаменте своего авторитета
(и занудства). И никто не даст гарантию, что очередная выбранная ко внедрению
практика не вызовет цепной реакции и не порушит всё, что вы сделали до этого.
Интересно, что оба способа основаны на вере в необходимость решения вопроса
качества управленческими методами. И самое главное, что вам придётся сделать
— поверить в то, что качество важно.
Членам религиозных конфессий (в частности, владельцам iPhone) поверить во что
угодно проще: так сказать, навык уже есть. Атеистам и андроидофилам — трудней,
хотя тоже возможно. Но да, увы, логика тут не работает: первым делом надо стать
адептом религии качества.
Чёрт, какая незадача: мы чуть не забыли, что работаем в IT. Кругом сплошная
логика, аналитика, аргументация и объективность. При чём тут вера? Да какое
значение имеют эмоции для того, чтобы работать в этой почти научно-технической,
левополушарной отрасли?
И тут мы возвращаемся к тому, что, казалось бы, стоило обсудить в самом начале
статьи. К вопросу о том, что такое качество.
Дело в том, что восприятие качества — крайне субъективно. Можно долго искать
(а найдя — даже и использовать) способы численно замерить какие-то отдельные
параметры некоторых составляющих процесса, проекта и продукта. Но в
результате же всё равно всё сводится к простому: нравится или нет, хочу или не
хочу, радует или бесит?
Психологи-экспериментаторы давно показали: люди не способны принимать
решения на основе фактов. Для каждого — даже самого маленького! — решения
нужны эмоции. И чем важней решение — тем меньше в нём логики и больше
эмоций.
Решение о качестве — это решение «хорошо—плохо». Вы хотите, чтобы кто-то
(пользователи, покупатели, начальство, акционеры, журналисты) оценили качество
вашей работы как «хорошо». Это значит, что вы хотите управлять эмоциями
людей.
А это невозможно делать механически, без вкладывания души. Невозможно.
Вам нужно, чтобы все участники проекта (а также его сторонники и противники вне
проектной команды) вложили в работу душу. А как насчёт вашей души? То-то и
оно.
Так что да, первый шаг безумно не-IT-шный — надо поверить.
Для тех, кто ещё не убеждён, привожу альтернативный аргумент. Британские
учёные :) доказали, что управление тем лучше, чем острее фокус менеджера на
http://www.pavlova.cc Страница 5
6. объекте управления. А для того, чтобы в условиях стресса, гонки и постоянных
помех внимание менеджера не соскальзывало с выбранного нами объекта
управления (то есть качества), нужно, чтобы менеджер был к этому объекту
эмоционально привязан. Для чего нет лучше способа, чем вера.
Как поверить в качество?
Прошу тех, кто уже верит, не пропускать этот раздел. Вдруг вера ваша слаба :)
Допустим, вы считаете, что качество вашего продукта на приемлемом уровне. Как
избавиться от этого досадного заблуждения? Вот несколько простых методов:
1. Почитайте, что люди пишут о вашем продукте. Невыразимо просветляющее
упражнение — пара дней работы в техподдержке. Чуть менее травматично, но
тоже неплохо — походить по форумам и блогам.
2. Постойте за плечом пользователя. Можно взять новичка, можно — матёрого
пользователя. Посмотрите, что человек делает и что он не делает.
Поспрашивайте о его обычных задачах в продукте, посмотрите, как он их
решает.
3. Сами станьте пользователем. Речь не о рассматривании интерфейса, а о
реальном использовании системы. Покупайте, пишите, публикуйте, считайте —
если, конечно, можете. В интернет-проектах это обычно несложно. Не
ограничивайтесь online-задачами — например, в интернет-магазине совершите
покупку целиком, а не просто до кнопки «Заказать».
4. Пользуйтесь конкурентами. Это поможет не только увидеть ваши слабые
стороны, но и, наоборот, начать больше ценить сильные. Кстати, и удержит от
поломки якобы никому не нужной (а на самом деле критически важной людям)
функциональности.
Ой, как будет неприятно. Вы будете ругать пользователей — мол, какие они
идиоты. Вы будете игнорировать то, что вам кажется несущественным — а потом
эти мелочи объединятся и станут грызть вашу совесть долгими зимними вечерами.
И поначалу вы будете действовать как робот — но мало-помалу у вас появятся
чувства, эмоции, нормальные человеческие ощущения.
Вот! Поймали! Эмоции и ощущения. Это ровно то, что нам надо: вы наконец смогли
почувствовать, что ваш продукт есть нечто большее, чем логика программы и
ограничения бизнес-процессов. Более того, вам станет в заметной степени
наплевать на «объективные причины» — желание сделать хорошо заглушит все
доводы в пользу того, что это, дескать, невозможно.
Поздравляю. Вы поверили в то, что качество — важно. И теперь готовы влиять на
это качество конкретными управленческими действиями.
Небольшой нюанс: упражнение нужно повторять непрерывно. Поддержка этой
веры — ваша ежедневная работа. А искушений отречься будет изрядно (не стоит,
http://www.pavlova.cc Страница 6
7. знаете ли, недооценивать могущество императора). Так что: пользуйтесь своим
каждый день, рассматривайте чужое раз в неделю, читайте пользовательские
отзывы раз в месяц — и говорите с людьми при каждой возможности.
Вредные привычки
Ну а теперь, наконец, самое вкусное: практические рекомендации. Начнём с
простого — попробуем искоренить свои собственные вредные привычки.
Вот они, эти враги — и методы борьбы с ними:
1. Маркетинговое мышление.
Как выглядит: решения принимаются на основе оценки потребности
большинства; штучные (пусть и экспрессивные) жалобы пользователей
игнорируются; мелкие детали интерфейса не прорабатываются; минорные баги
не чинятся.
Что делать: осознать, что пользователям наплевать на большинство; испугаться
шума в блогах из-за одной, но очень некрасивой ошибки; выработать в себе
уважение к каждому (!) пользователю.
2. Ложь при планировании.
Как выглядит: сроки реализации конкретной задачи навязываются сверху без
учёта возможностей производства.
Что делать: не подписываться под сроками, если ощущаете давление;
согласовывать сроки с производством; регламентировать процедуру
согласования сроков.
3. Отсутствие сдачи-приёмки.
Как выглядит: факт сдачи задачи автоматически означает в глазах
исполнителя её приёмку; возврат на доработку воспринимается как личное
оскорбление.
Что делать: планировать итерации сдачи-приёмки; оперативно выкатывать
список недоработок к исправлению.
4. Озадачивание без контроля.
Как выглядит: задача выдана, но её реализация не проконтролирована;
разборки задним числом вида «А я ещё в мартобре просил тебя сделать».
Что делать: считать контроль исполнения отдельной задачей; ставить
напоминалки; вести учёт в списке дел.
5. Электронная почта.
Как выглядит: заметная часть рабочего времени уходит на электронную почту;
участие в малозначимой переписке; подробные письменные обсуждения; прочая
имитация бурной деятельности.
Что делать: проверять электронную почту не чаще раза в час; вести отдельный
список дел.
6. Много букв в документации.
Как выглядит: солидная пачка бумаги названа «техническим заданием»; никто
http://www.pavlova.cc Страница 7
8. не сверяется с документацией в процессе разработки.
Что делать: не вести документацию; ставить задачу в формате прототипов
интерфейса; не описывать очевидное; ключевые требования умещать на 1-2
страницы A4.
7. Устное целеполагание.
Как выглядит: цели проекта «всем известны», но короткого описания — нет.
Что делать: составить и согласовать документ — обоснование проекта.
8. Игнорирование идиотов.
Как выглядит: странные запросы людей, не имеющих отношения к проекту (но
имеющих влияние в компании), спускаются на тормозах.
Что делать: общаться с ними (обычно они хотят только общения); согласовывать
их хотелки с генеральным заказчиком; найти способ повлиять на их точку
зрения и воспользоваться этим способом.
9. Сокрытие информации.
Как выглядит: работа идёт, но для того, чтобы составить себе впечатление о
происходящем, людям со стороны нужно проявить инициативу и
поинтересоваться.
Что делать: индивидуально активно информировать ключевых сотрудников;
направо и налево рассказывать о проекте.
10. Нерегулярный current state.
Как выглядит: встречи рабочей группы проводятся от случая к случаю.
Что делать: жёстко зашить встречи в календарь; приглашать на встречи
заказчика; письменно фиксировать и публиковать резюме встречи.
11. Невнимание к инициативам.
Как выглядит: предложения рядовых исполнителей игнорируются или
встречаются «в штыки».
Что делать: предлагать исполнителям развить тему (регламентировать, сделать
пробный вариант, провести презентацию или анализ рынка); рассказать об уже
существующих попытках решить задачу и предложить включиться в процесс.
12. Поощрение посредственности.
Как выглядит: плохо сделанная работа принимается из-за недостатка внимания
или времени.
Что делать: отправлять на доработку со списком замечаний; заказывать работу
двум исполнителям одновременно.
13. Невнедрение.
Как выглядит: исполнитель сделал «срочную» работу, которая после этого
попала в длинную очередь на публикацию или внедрение.
Что делать: пользоваться методикой kanban (заказывать только то, что можно
будет сразу опубликовать или внедрить).
14. Микроменеджмент.
Как выглядит: слишком частый контроль прогресса, слишком детальные
инструкции.
http://www.pavlova.cc Страница 8
9. Что делать: детальные инструкции выдавать только после того, как стало ясно,
что самостоятельно исполнитель не найдёт способ решить задачу на должном
уровне качества.
15. Серьёзность.
Как выглядит: агрессивная пропаганда «важности и нужности» решаемых
задач.
Что делать: шутить над продуктом; закладывать «пасхальные яйца» для своих.
16. Недоверие.
Как выглядит: пренебрежительные высказывания о результатах чужого труда и
о возможностях исполнителя в целом.
Что делать: претензии, если они есть, высказывать без обобщений («ты
всегда»), максимально конкретно и конструктивно.
Активности по этапам
В предыдущем разделе мы, как положено порядочным управленцам, начали с себя.
Но рано или поздно придётся перейти к изменению организации труда рабочей
группы проекта. Проще всего коррекция идёт, если её синхронизировать с типовым
производственным процессом, уже принятым в вашей компании.
Все интернет-проекты обычно идут по одной и той же схеме (как бы нам с вами ни
хотелось думать иначе). Этапы этой схемы можно обозначить, например, так:
1. Формирование идеи (созревание проекта, оформление сделки, предоплата).
2. Старт (выделение ресурсов и предварительное планирование).
3. Аналитика (бизнес-требования, анализ рынка, техническая постановка).
4. Проектирование (интерфейс, дизайн, тексты).
5. Разработка (покомпонентное программирование, интеграция, вёрстка).
6. Тестирование (функционал, нагрузки, бета).
7. Запуск (внутренняя презентация, вывод в свет, PR, обработка feedback'а).
8. Сдача в эксплуатацию (доработки, регламентация, сдача-приёмка, обучение,
оплата).
Конечно, эти этапы отнюдь не идут аккуратно след в след, а наоборот, как хотят
заползают друг на друга в произвольном порядке. Обычно это невинное, в
сущности, явление природы приравнивают чуть ли не к стихийному бедствию: мол,
раз всё так запутано и идёт не по порядку, то и планировать работы не нужно и
контролировать их качество не получится.
Это немножко неправда. Смотрите, какая разница, в какой последовательности
идут работы, если они в любом случае должны быть сделаны? Ну вам правда, что
http://www.pavlova.cc Страница 9
10. ли, важно, что разработка начнётся до фиксации бизнес-требований? Вы же не
бросите бизнес-требования на полдороги — они же всё равно нужны в более-менее
цельном виде, правда?
Да, но при чём тут качество? Дело в том, что фокусировка на качестве
промежуточных результатов — один из самых простых (хотя и не единственный)
способ управлять качеством процесса. Особенно в интернет-проектах: ведь
каждая задача (даже монструозная разработка какого-нибудь универсального
движка) либо невелика, либо её можно разбить на несколько задач помельче.
Но ведь важно ничего не пропустить! Все подзадачи, которые нам предстоит
делать на проекте, должны быть учтены могучим ураганом хотя бы в момент
старта. Составить достаточно детальный список задач (план без дат и
взаимозависимостей) — первый шаг к такому учёту.
Какие задачи включать в этот список, а какие нет? Вспомним про качество. Мы
управляем качеством? Да. Значит, список задач (зародыш плана) должен нам
помочь управлять качеством? Тоже да. А какой у менеджера вообще арсенал
инструментов управления? Очень небольшой: менеджер умеет ставить задачи и
принимать результат их исполнения.
Мда, негусто. Но зато на раз-два помогает разобраться, какие задачи нужно учесть
в плане. Ровно те, которые вы собираетесь ставить — и которые будете
принимать. Не больше, не меньше.
Несколько примеров:
1. Тестирование конкретного кейса может быть задачей из плана — если вы
хотите лично проконтролировать, что он работает. А может и не быть — если
это второстепенный кейс, и таких у вас 300 штук уйдёт в отдел тестирования.
2. Прототипирование главной страницы сайта — всегда задача из плана: вы
намучаетесь и с постановкой, и со сдачей-приёмкой. А вот прототипирование
страницы «Наши банковские реквизиты» — почти никогда: сделают, и ладно.
3. Запуск как таковой (включение сайта) — всегда задача из плана. А проведение
пресс-конференции — скорее стихийное бедствие, что тут запланируешь.
Итак, список задач есть. А теперь начинается самое интересное. Как вы
собираетесь контролировать качество их реализации? Есть несколько методов:
1. Повысить качество постановки. Не объём, а качество. Возьмите личную
ответственность за то, чтобы постановка соответствовала вашим ожиданиям:
напишите, проверьте, согласуйте и т.п.
2. Делегировать задачу. Когда за дело отвечает «отдел» — туши свет. Когда за
это же дело отвечает конкретный сотрудник отдела — начинаются чудеса.
Никто, кроме самых уж отморозков, не хочет делать свою работу плохо. Значит,
всё, что в ваших силах — дать работе хозяина. Конечно, так, чтобы хозяин
захотел эту работу выполнить и был горд результатом — но обычно тут дело
нехитрое.
http://www.pavlova.cc Страница 10
11. 3. Спланировать сдачу-приёмку. Никакую работу нельзя сдать с первого раза,
всегда возникают подводные грабли. Планируйте не сами грабли, а итерации их
выявлений: первый вариант — обсуждение — список багов — второй вариант —
… — последний (обычно третий) вариант. На всё это уходит время — но мы же
о качестве?
4. Явно подтверждать окончание задачи. Поставили точку в бизнес-
требованиях — всё, поставили. С этого момента все дополнительные хотелки не
падают автоматом на голову несчастных исполнителей, а становятся вашим
личным геморроем: отметайте, защищайте, обещайте вторую версию, но
держите ответственность за эту поставленную точку. Не факт, что получится,
но надо пытаться.
Вот такая работа с планом. Не безумно сложная, но требующая изрядного
занудства. И понимания: вы боретесь за каждую запятую сейчас — не потому, что
вам так нравится, а потому что только равномерно обеспеченное качество
процесса приведёт к приемлемому результату.
Давайте теперь вернёмся к основным этапам и перечислим ключевые задачи
менеджера, исполнение которых приведёт к повышению качества и процесса, и
продукта:
1. Формирование идеи
1.1. Явно и письменно зафиксировать обоснование проекта: что, зачем и с
какими ограничениями делается.
2. Старт.
2.1. Явно и письменно согласовать имена заказчика и руководителя проекта.
2.2. Письменно составить список задач проекта (зародыш плана).
3. Аналитика.
3.1. Провести презентацию решений конкурентов.
3.2. Лично прочитать и обсудить техническую постановку.
3.3. Явно и письменно составить портрет целевой аудитории.
3.4. Письменно зафиксировать пользовательские ожидания (хотя бы список).
3.5. Требовать коротких документов, не принимать тома постановки.
4. Проектирование (интерфейс, дизайн, тексты).
4.1. Отделить проектирование интерфейса от дизайна.
4.2. Лично сверить интерфейс и дизайн с пользовательскими ожиданиями.
4.3. Лично прочитать все тексты.
http://www.pavlova.cc Страница 11
12. 4.4. Прогнать все тексты через корректуру.
4.5. Наладить контроль работы дизайнера со стороны проектировщика.
5. Разработка.
5.1. Каждые 2-3 дня выяснять current state по разработке.
5.2. Поддерживать постановку в актуальном состоянии.
5.3. Лично отсматривать вёрстку перед отправкой в тестирование.
6. Тестирование.
6.1. Лично прочитать и обсудить постановку на тестирование.
6.2. Индивидуально презентовать бету каждому ключевому бета-тестеру.
6.3. Изолировать разработчиков от дискуссий с бета-тестерами (это не самый
однозначный совет, но я стараюсь так делать).
7. Запуск (внутренняя презентация, вывод в свет, PR, обработка feedback'а).
7.1. Сообщить все публичные даты проектной команде, напоминать регулярно.
7.2. Лично живьём объяснить ключевым представителям заказчика процедуру
запуска.
7.3. Участвовать в обработке feedback'а.
7.4. Хорошие новости о запуске сообщать проектной команде.
7.5. Публично поблагодарить проектную команду (если возможно, каждого
индивидуально).
8. Сдача в эксплуатацию (доработки, регламентация, сдача-приёмка, обучение,
оплата).
8.1. Не забыть про этот этап :)
Конечно, есть и другие практические действия, специфичные для вашего
производственного процесса. Вы сами легко их назовёте. Но всех их объединяет
одно: личный контроль менеджера за процессом и результатом работы.
При должном упорстве и вере в светлое будущее, как и было выше сказано,
производственный процесс рано или поздно подчинится внедряемой вами системе
управления качества.
http://www.pavlova.cc Страница 12
13. Поддержка единомышленников
Ваши единомышленники — это люди, которым нравится делать свою работу
хорошо. То есть большинство.
Вы же с ними на одной стороне баррикад, правда?
А значит, надо быть готовым на кое-какие компромиссы:
1. Поверьте, они правда лучше знают. Особенно разработчики. Довольно часто
менеджеры пытаются влезть в дебри разработки. Наверное, для того, чтобы
почувствовать проект «на кончиках пальцев», ощутить сопричастность к
физическому, так сказать, процессу производства. Управлять скучно и
неприятно — то ли дело руками самому что-то делать. Но знаете, не надо.
Лучше сказать: «Ты лучше знаешь то-то и то-то, а я не понял, поясни,
пожалуйста».
2. Им нужно время. Много времени. Ужас в том, что о времени спрашивают не их,
а вас. И велик соблазн прогнуться и пообещать что-нибудь красивое. Нет. Ваша
работа — не прогибаться в этом вопросе. Поверьте, ускорение производства
начинается отнюдь не с повышенных обязательств (жаль, что тут нет
возможности подробней раскрыть эту тему).
3. Виноватых нет. Если вдруг кому-то и где-то придёт в голову искать виноватых
— соблазнительно свалить всё на исполнителя. Хорошая затея, но
деструктивная: очень расхолаживает, убивает инициативу и желание работать
вообще. Решайте сами, как сделать так, чтобы исполнители не попадали в
виноватые. Подсказка: кругом масса кандидатов.
4. Помогайте договариваться. Исполнителям трудно договариваться даже друг с
другом. А уж с отделом маркетинга… Ищите ростки недопонимания и
устраняйте их всеми силами. Как только контакт налажен — отходите в
сторону, без вас разберутся.
5. Пропагандируйте. Вообще-то обычно в небольшой компании и так всем
известно, кто трудяга, а кто лентяй. Но лишний раз порекламировать чудо-
сотрудника окружающим (особенно директорам) — дело хорошее. Вам ведь
нужно, чтобы ваши единомышленники набирали авторитет. А вот ругать — это
уже не работа, а политика, занимайтесь ею на свой страх и риск.
Интересно, что люди, которые хотят работать хорошо, больше всего на свете ценят
обратную связь. А в обратной связи — конструктивные предложения, которые
помогают им сделать лучше и эту конкретную, и все дальнейшие аналогичные
задачи.
Самый прекрасный подарок, который вы им можете сделать — это помочь
научиться работать лучше. Поэтому не скупитесь на обратную связь и искреннюю
благодарность за хорошо выполненную работу.
http://www.pavlova.cc Страница 13
14. Вот и всё на сегодня. За скобками осталось довольно много нюансов.
Как, например, увязать вопросы качества с вечной нехваткой времени?
Что делать с криворукими уродами (а такие встречаются)?
Можно ли материально поощрять тех, кто хорошо работает?
Есть ли всё-таки способы количественной оценки качества?
Но знаете, все эти вопросы как-то сами собой решаются, если сделать главное.
Так что о них, наверное, в следующий раз — когда вышеописанное станет для вас
набором отскакивающих от зубов банальностей :)
http://www.pavlova.cc Страница 14