Аналитика малых задач

Хочу поднять одну тему, которая, возможно, стала знакомой, близкой и от того мало любимой. Она порождена тем, что использование подходов создания больших систем к разработке малых задач (скажем, трудоемкостью до 500 человекочасов) приводит к тому, что стоимость конечного продукта зашкаливает за все разумные плоды воображения. Как так происходит?

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

Исходя из того опыта, который мы огребаем в последнее время, для реализации малых задач характерны следующие особенности:

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

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

1. Не смотря на то, что в целом на проектах предметная область по сути одна и та же, между конкретными разными проектами она различна и перебрасывание аналитиков с проекта на проект с целью обеспечить их максимально возможную загрузку приводило к размазыванию экспертизы. Т.е. все знали примерно все, но мало кто знал что-то конкретное.
2. От девелопмента и тестирования в аналитике никто особо не участвовал. В итоге при передаче аналитики в разработку команда смотрела на функциональный дизайн как собрание сами можете представить кого на новые ворота.
3. Продукт, разработанный командой, в которой была пропасть между анализом и разработкой, не был способен вызвать положительные эмоции у конечных пользователей.
4. Поскольку проекты в основной своей массе были небольшими, изначально было принято ложное мнение, что для их анализа нет смысла привлекать синьоров. А молодежь в свою очередь по банальной неопытности не отрабатывала требования на предмет их полноты и непротиворечивости, что в ходе разработки приводило к изменениям границ проекта.
5. Невысокая квалификация специалистов также являлась причиной того, что при организации своей работы они исходили не из целесообразности выполнения задач, а из фэн-шуя, описанного в различных методологиях.
6. При проведении аналитики акцент значительно смещался на функциональный дизайн приложения в ущерб пониманию Бизнеса и его потребностей.
7. В команде отсутствовала единая методология выполнения работ. Каждый аналитил исходя из личных соображений, особо не оглядываясь на опыт ближайших коллег.
8. Наши аналитики были не способны предложить альтернативные решения. Зачастую решения, интересные Бизнесу, попросту “выпытывались”.

Исходя из всего этого были сформулированы следующие требования к ведению аналитики на малых проектах:

1. Аналитик должен очень хорошо знать предметную область проекта, понимать проблематику и иметь плотный контакт с Бизнесом. Знать ее так, чтобы быть способным предложить Бизнесу грамотные альтернативные варианты реализации поставленной задачи. Аналитик должен знать основные системы Бизнеса, их функциональность.
2. Промежуточные аналитические решения должны регулярно доноситься до команды (как минимум до лид девелопера) и обсуждаться. На момент начала аналитики на проекте уже должен быть лид девелопер.
3. Аналитик должен максимально вовлекать в свою работу тестера.
4. Аналитик должен регулярно ревьюить то, что пишут девелоперы, а по завершении разработки прочекать приложение на предмет его соответствия ожиданиям Бизнеса.
5. При организации работ аналитик должен идти по классическому вектору типа цели – бизнес-требования – as is – to be – сценарии использования – требования, но при этом исходя из поставленной задачи уметь исключить “лишние” работы и сделать необходимый и достаточный минимум.
6. Половину своей “проектной жизни” аналитик должен проводить на территории Бизнеса. Ничто так не решает проблемы, как регулярное очное общение.
7. Бизнес-смысл решаемой задачи должна знать и понимать вся команда.
8. Все направления автоматизируемого Бизнеса должны перекрываться синьор-аналитиками.
9. Презентацию продукта Бизнесу должен делать аналитик. Он также должен присутствовать на территории Заказчика во время начала эксплуатации продукта.

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