Проекты с идеальным порядком, к сожалению, встречаются крайне редко. Чаще всего мы сталкиваемся с хаосом разной степени беспорядочности: от «черт ногу сломит» до мелких проблем, лишь изредка дающих знать о себе (например, при появлении новых сотрудников). Но, закрывая глаза даже на совсем небольшие дефекты, мы все больше приближаемся к настоящему «апокалипсису», способному «убить» самые интересные и стабильные проекты. Все как в «теории разбитых окон»: чем чаще мы не замечаем проблемы – тем больше их становится, и тем прочнее они внедряются в нашу жизнь. Увы, по-другому не бывает.
Я, как и многие другие, ни разу не видела идеальных проектов. Порой на попытки разобраться, что к чему, уходило совершенно неприличное количество времени, что сводило всю эффективность работы на нет. В этой статье я расскажу о различных оттенках хаоса, с которыми мне доводилось встречаться, а также поделюсь вариантами решения каждой из проблем.
7 оттенков хаоса, и как с ними бороться
1. Плохо сформулированные требования.
Пожалуй, это самая распространенная проблема. На мой взгляд, полностью соответствующее требованиям техническое задание (ТЗ) можно сравнить со снежным человеком: вроде бы, про него все слышали, но точных доказательств существования нет. Мне тоже не доводилось встречаться с этой «неведомой зверушкой», поэтому каждый проект приходится начинать с выяснения степени актуальности и полноты существующих требований.
На одном из моих самых первых проектов требования были написаны абсолютно на каждую функциональность. К сожалению, они были сформулированы настолько непонятно, что разработчики, тестировщики и ПМ очень редко с первого раза одинаково понимали изложенное. И это было не единственной проблемой: ТЗ примерно на 80% состояло из устаревшей информации, так как аналитик практически никогда его не обновлял. В результате продукт получался совсем не таким, как задумывал заказчик. Правильность реализации каждой функциональности становилась предметом длительных обсуждений и споров между членами команды. Утомительный процесс постоянно приводил к срывам сроков разработки.
- Вычитка и обсуждение требований со всеми причастными еще до начала разработки (или хотя бы до начала тестирования) помогает всей команде получить одинаковое представление о том, как должен выглядеть продукт. Вычитку могут проводить абсолютно все или только некоторые сотрудники – главное, чтобы в итоге информация была донесена до всего коллектива.Мы делали так: поскольку время на составление тестов было ограничено, ТЗ пристально рассматривалось уже в процессе подготовки чек-листов, а затем задавались вопросы аналитику. После выяснения всех моментов требования обновлялись, чек-листы согласовывались с аналитиком и предоставлялись на ознакомление разработчикам. Это пошло проекту на пользу: споров стало гораздо меньше, функциональности реализовывались в соответствии с видением заказчика, в процессе тестирования не нужно было выяснять, что и как должно работать. Разработчики все реже получали сюрпризы в виде рекомендации «надо было сделать совсем иначе».
- Исследование продукта и параллельное сравнение с ТЗ – полезно в том случае, когда разработка завершена, но нужно написать тесты. В этом случае я всегда задаю вопросы человеку, ответственному за требования, выясняю все непонятные моменты, нахожу и уточняю причины отличий между продуктом и ТЗ, а затем вношу изменения в тесты. Тестируемое приложение в итоге становится «прозрачнее», благодаря чему и тесты писать гораздо проще.
2. Отсутствие требований.
Проблема эта также встречается довольно часто, но, как мне кажется, отсутствие требований – это все-таки лучше, чем ТЗ сомнительного качества. Сделать все «с нуля» в разы легче, чем пытаться «распутать клубок» из замысловатого текста, устаревшей информации и сплошной недосказанности.
Не так давно мне попался проект, в котором нужно было регулярно проводить тестирование новых функциональностей и заодно проверять старые «фичи». Очень важно было не пропускать баги, поскольку сайт давно попал в руки реальных пользователей, тративших свои деньги. При этом требования хранились в голове у менеджера, а разработчики все делали по задачам в багтрекере. Тестировать нужно было «здесь и сейчас», а потому писать ТЗ было просто некогда. К счастью, мне очень повезло: менеджер понимал необходимость документирования проверок и выделил время на составление тестов. Это стало моей «палочкой-выручалочкой».
- Идеальный вариант – создание ТЗ с нуля, как это ни банально звучит. При наличии запаса времени грамотный аналитик (или тестировщик) тщательно соберет всю информацию и напишет прекрасные требования, которыми сможет пользоваться вся команда. В дальнейшем останется только актуализировать их при появлении изменений.
- Составление тестов — помогает «убить сразу двух зайцев»: получить как представление о продукте, так и собственно тесты, по которым можно проверять сервис. Любые изменения необходимо будет вносить только в один документ (это еще один плюс).
- Создание псевдо-требований в виде таблички, в которой собраны ссылки на источники информации по каждой функциональности. Этот вариант хорош, когда на проекте все описание продукта содержится только в багтрекере или разбросано по разным документам.
Конечно, есть еще вариант «забить и тестировать по памяти», но многие знают, что память может подвести в любой момент, поэтому не будут полагаться на такой вариант.
3. Каждый оформляет документацию так, как хочет.
Наличие документации на проекте – это само по себе уже замечательно. Но если каждый сотрудник составляет одни и те же документы по-своему, то в какой-то момент можно столкнуться с ситуацией, когда половина записанной в них информации станет либо совсем ненужной, либо мало кому понятной. Всегда проще разобраться в типовых по структуре документах, чем каждый раз пытаться вникнуть во что-то новое.
Мне не раз приходилось сталкиваться с одними и теми же багтрекерами, где все дефекты заводились по-разному: в одних были шаги, в других – нет, где-то фактический результат стоял перед ожидаемым, а где-то – наоборот. Такая же ситуация могла сложиться и с чек-листами: один тестировщик разбивал проверки на группы и проставлял приоритеты, а второй записывал все подряд. Все это приводило к тому, что ценное время тратилось на попытки переключиться с одного вида изложения информации на другой.
- все будет выдержано в едином стиле (особенно полезно в отчетах, отправляемых заказчику);
- новички всегда будут знать, как и что им делать, и какая информация должна содержаться в документе;
- сокращается время сбора данных о том, что необходимо включить в очередной отчет, и как должна выглядеть стратегия тестирования;
- можно сразу настроить поля, которые необходимо заполнять (если позволяет багтрекер).
Всегда проще взять готовый шаблон и наполнить его нужной информацией, чем создавать свой документ с нуля.
4. Непонятно, какие задачи выполнять, и что делать дальше.
Уверена, что я не единственная, кто прошел через всю боль попыток получить ответ на простой вопрос: чем нужно заниматься после выполнения порученной работы. Самое неприятное – «висеть» в ожидании задачи и вообще ничего полезного в этот период не делать. Такое чаще всего бывает с новичками в команде (и не важно, джуниоры это или опытные специалисты). Они не разбираются в проекте, не знают, какие есть проблемы, и до чего часто не доходят руки, поэтому могут так и просидеть день-другой без дела, пока им не дадут новое задание. Особенно остро этот вопрос стоит в послерелизное время: «полный завал» внезапно прекращается после выпуска продукта на продакшен, и всем вдруг становится нечего делать.
- доска в системе багтрекинга (если она используется на проекте) – всегда можно наглядно посмотреть, что сделано, над чем еще ведется работа, а к чему еще не приступали;
- табличка в том же Google Drive, где собрано описание всех задач с исполнителями и статусами готовности. Например, табличка может быть такой:
Самое главное тут – обеспечить сотрудникам постоянную занятость и отсутствие простоев. И дело вовсе не в том, что каждый должен приносить пользу команде и не сидеть зря, а в том, что проводить время без дела скучно и неинтересно. На любом проекте найдутся задачи, на которые никогда не остается времени (например, устаревшая документация).
Я уже не говорю о том, что без плана работы вообще сложно представить себе какой-либо более-менее успешный проект. Сотрудники должны всегда знать, чем им заниматься дальше (особенно в условиях интенсивной работы над продуктом), иначе вскоре на проекте возникнет настоящий хаос, начнут появляться простои, а за ними последует и неминуемый срыв сроков. Поэтому заблаговременным планированием задач и их распределением между всеми членами команды не стоит пренебрегать.
5. Непонятно, что и как тестировать.
Еще один «всадник Апокалипсиса». Как сейчас, помню: открываешь задачу, хочешь проверить, но там вообще почти никакой информации, а разработчики общаются друг с другом кодом. Я прекрасно понимаю, что хороший тестировщик должен знать языки программирования, и не пренебрегаю этим навыком. Но ситуации бывают разные – например, появление новых сотрудников, что время от времени бывает на любом проекте. Да по прошествии времени гораздо легче понять, что было сделано в рамках давно забытой и протестированной задачи.
- четкое и понятное описание: как все должно работать и какие функциональности могли быть затронуты в процессе написания кода;
- хотя бы пару строк в комментариях от разработчика о том, что и как сделано (если уж так получилось, что другого описания нет).
Такие задачи значительно облегчают работу тестировщику и экономят его время на попытках выяснить, что к чему. Намного проще придумывать сценарии проверки на основе описания функциональности, чем сначала собирать информацию по крупицам, а потом уже приступать к тестированию. Особенно остро проблема стоит в распределенных командах и при удаленной работе, когда нет возможности подойти к коллеге и решить вопрос за 5 минут.
Кстати, связи между частями продукта легко отслеживать с помощью карты функциональностей. Такую «штуку» всегда полезно иметь под рукой. Допустим, разработчики исправили баги в каком-то модуле (а проблемы в итоге появились в другом) или добавили новую «фичу» (сразу понятно, что еще нужно проверить во время регрессионного тестирования). На карте можно увидеть, какие блоки имеет смысл проверить вместе с исправленной или новой функциональностью, а также какие есть связи и приоритеты. Это снимет целый ряд вопросов, поскольку все и так наглядно.
6. Непонятно, кто и за что отвечает.
Наверняка каждый сталкивался с ситуацией, когда было не очень понятно, к кому и с какими вопросами можно обращаться. Я – не исключение. Спросишь что-то у коллеги – а в процессе выясняется, что это обязанность совсем другого человека, к которому и нужно идти за ответом. Такое чаще всего бывает на новом месте работы, где многое еще непонятно. Да и в относительно стабильных коллективах периодически наступают перемены, когда инициируются какие-то перестановки и меняются или перераспределяются обязанности, – и вот уже даже опытный работник может запутаться.
- создать справочник по обязанностям и должностям сотрудников (потом при необходимости всегда можно заглянуть в такую шпаргалку);
- описать, кто конкретно в компании отвечает за нестандартные вопросы, повышение зарплат и может помочь в непонятных ситуациях. Никто не отменял форс-мажоры, конфликты и банальное желание повысить доход – сотрудники должны понимать, с кем это все можно обсудить.
7. Непонятны статусы выполнения задач.
Мне кажется, всем знакома такая ситуация: задачи распределены, все разошлись по своим рабочим местам и спокойно «фигачат», но проходит время, а статус выполнения заданий не ясен. Конечно, можно просто периодически устраивать опрос, но при этом существует риск получить «размытую» информацию, ничего в итоге не понять и, как следствие, увидеть проблему не сразу, а лишь когда начнут поджимать сроки. Я тоже спотыкалась об эти грабли, особенно когда на проекте трудилось очень много людей: в итоге я вообще не очень представляла, что происходит.
- создаю в них список задействованных сотрудников;
- описываю задачи, которые за всеми закреплены.
В процессе работы каждый сотрудник заходит в таблицу и проставляет статусы по мере выполнения. Это дает возможность оценить объем уже сделанного и понять, сколько еще осталось. Таким образом, появляется полная картина ситуации на проекте, и не приходится донимать людей вопросами. Помимо статусов и задач в табличку можно добавить колонки для комментариев и любой другой информации (на случай возникновения непредвиденных проблем): сразу будет видно, где именно и по какой причине выполнение задачи отложено или затруднено, а также что можно сделать в данном случае. А еще таблица не раз помогала мне легко и быстро предоставить информацию о статусе проведения работ руководителю, который внезапно озаботился состоянием проекта.
Ниже можно посмотреть примеры таблиц, которые я часто использую в работе.
Что в итоге?
Наш мир, к сожалению, устроен так, что в нем никогда не бывает идеального порядка: мы часто не успеваем, забываем или просто ленимся что-то делать. Из-за этого срываются сроки и нарушаются обязательства, что влечет за собой и другие проблемы. И только в наших силах сделать так, чтобы беспорядок если и не полностью исчез, то хотя бы стал значительно менее ощутимым. Игнорируя проблемы, мы способствуем тому, что хаос, подобно сорняку, прочно врастает своими корнями в любой проект, нарушая его целостность и внутреннюю гармонию.
Каждая из перечисленных рекомендаций опробована на моем личном опыте и на опыте моих коллег. На первый взгляд, эти советы очень просты и не содержат в себе каких-то особых премудростей, но именно простые варианты часто упускаются из виду. Мы нередко ищем какой-то сложный путь, не обращая внимания на то, что лежит на поверхности. Надеюсь, что те пути решения проблем, которые я предложила в статье, помогут вам справиться с зарождающимся или уже появившимся на проекте беспорядком.
