воскресенье, 26 июня 2011 г. - www.msmirnov.ru

Летний Аналитический Фестиваль-2011 (ЛАФ-2011)

Вчера я посетил наверное уже ставший традиционным Летний Аналитический Фестиваль-2011 (ЛАФ-2011), который как и в прошлом году проходил в Иваново и был посвящен системному анализу.

О ЛАФ-2010 я писал здесь и здесь.


Было приятно увидеть множество знакомых лиц с прошлого фестиваля.

Как и в прошлый раз фестиваль прошел в теплой непринужденной, я бы даже сказал дружеской, и вместе с тем, профессиональной обстановке.

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


Лично для себя я отметил следующие доклады:


1. Ирина Левенец "Управление ожиданиями в продуктовой разработке". На мой взгляд интереснейший доклад.

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

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

Поэтому, с течением времени уровень сервиса, который предоставляются заказчику, растет, но не смотря на это, недовольство заказчика тоже растет.

Соответственно, ценность сервиса для заказчика снижается.

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

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

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

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

- Меньше обещать, больше делать. Т.е. если мы пообещаем заказчику сделать что-то например за неделю, и сделаем за неделю - это хорошо. А вот если мы пообещаем сделать за две недели, а сделаем за неделю - это будет просто отлично, заказчик будет счастлив.

- Если что-то не может быть сделано - так и сообщать заказчику. Не говорить, что может быть мы когда-то потом это сделаем.

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


2. Сергей Мартыненко "Варианты управления требованиями". Как и в прошлом году, у Сергей был очень интересный доклад.

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

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

 Почему все эти методы плохие? Потому что в релиз попадают фичи, без учета их общей ценности, зависимостей, влияния на архитектуру и пр.

- Хороший способ распределения требований по релизам:

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


3. Денис Казика. "Внедрение ITIL/ITSM" Тоже довольно интересный доклад.

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

Для решения проблем были предприняты следующие шаги:

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

- Были внедрены внутренние регламенты работы IT-подразделения.

- Был стандартизирован парк оборудования и программного обеспечения, использующего в кампании.

- Была введена должность бизнес-аналитика.

Весь процесс занял примерно 2.5 года.


После всех преобразований:
- IT-подразделение стало бизнес-образующим.

- Исчезли конфликты между IT-подразделением и другими подразделенями.

- Бизнес компании стал более эффективным.


4. Алексей Киселев "Могут ли быть выгодны ошибки аналитика или история одного тендера".

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

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

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

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

- Гос.заказчики не признают итеративную разработку. Только водопад.


Пожалуй, это были самые интересные для меня доклады.


К сожалению мне не удалось попасть на мастер класс Дмитрия Безуглова, но я надеюсь увидеть его как-нибудь позже.

Кроме того, не удалось побывать на интересном мастер-классе Ирины Векленко "Анализируй это: Жизнь как Проект", но я также надеюсь пообщаться с ней позже.

Еще хотелось бы отметить, что несколько раз в перерывах между докладами, аналитик Павел Сафин радовал всех собравшихся виртуозной игрой на рояле, за что ему отдельное большое спасибо!


Я надеюсь, что в следующем году состоится ЛАФ-2012 и буду очень рад присутствовать на нем.

Хотелось бы поблагодарить всех организаторов и участников фестиваля за то, что они делают!


All you need is... ЛАФ!
Мой сайт - www.msmirnov.ru

среда, 22 июня 2011 г. - www.msmirnov.ru

Сложности распределенных команд и проектов

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

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

Еще хочу обратить внимание, что данные проблемы не являются не решаемыми.

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


1. Часовые пояса.
Большая разница во времени (например, 12 часов) существенно замедляет процесс разработки.

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

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

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

Можно, конечно, не задерживаться, а просто написать письмо, но это еще хуже.

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


2. Языковой барьер.
Де-факто инструментом общения сейчас является английский язык.

Писать и читать на нем все более или менее уже научились.

Намного сложнее слушать и быстро отвечать.

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

Еще хуже когда таких собеседников несколько одновременно и нужно успевать понимать, что все они говорят.

Ну и совсем плохо, когда все они с сильным акцентом быстро и одновременно говорят по conference-связи с плохим качеством, при котором часть звуков и слов просто пропадает.  



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



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


5. Демотивация.
Предыдущий пункт приводит к демотивации членов команд, так как они не чувствуют глубокой причастности к работе над проектом. Проект на становиться для них, что называется “своим”.

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


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


6. Сложности в соблюдении единого стиля разработки.
Это касается как стандартов кодирования, так и технических и архитектурных решений.


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



7. Сложности во вскрытии проблем.
Проектные подгруппы и отдельные сотрудники незаинтересованны в потере собственного авторитета. Поэтому они, при возможности, могут перекрывать путь для негативной информации. Это возможно в силу затрудненности коммуникаций. Такое развитие событий может приводить к неразрешимым проблемам в проекте.


8. Важные вопросы могут решаться не по принципу выбора верного решения из нескольких возможных, а по принципу близости протеже решений к руководству. Последствия, я думаю, очевидны.
Мой сайт - www.msmirnov.ru

понедельник, 20 июня 2011 г. - www.msmirnov.ru

Поздравляю Андрея Маркеева!

Хочу поздравить Андрея Маркеева с отличным выступлением на Sharepoint User Group!

Всегда приятно видеть, как человек своими личными усилиями достигает новых планок в своей профессии.
Мой сайт - www.msmirnov.ru