Нет более неблагодарной работы, чем подготовка отчетов и постоянное подтверждение, что ты тот самый, в то самое время, на том самом месте.
Когда приходишь в новый проект сложно как-то сразу приносить пользу на 100%.
Сперва идет обучение - тебя учат, и ты, скорее, тратишь время команды и отдельных ее специалистов.
Потом ты учишься сам, и, вроде бы, никто так много времени на тебя не тратит, но все равно польза не кажется такой же ощутимой, как от других коллег.
Потом, наконец, выходишь в автономку и начинаешь что-то делать, почти без внимания со стороны.
Потом даже учишь сам. Прогресс...
И вот как тут во время обучения понять, что важно и как донести эту самую нужную важноту?
С другой стороны попадают и "старшеклассники". Многие начальники время от времени любят чесать свой авторитет и спрашивать "чем-ты-занимался-все-это-время". Тут сложно сказать однозначно, насколько начальник прав "внезапно" начав задавать вопросы, которые раньше не звучали. Это может быть и вопрос вышестоящего руководства к нему, и даже неуверенность, что он опять перестал понимать - какая от тестировщика польза (баги в проде вдруг перестали находить, так это так разработчики постарались).
Нужно держать руку на пульсе. Как? Сегодня я хотел бы поговорить об этом.
ОТЧЕТНОСТЬ
Время потраченное на составление берется из времени, которое можно потратить (по мнению большинства коллег) на более полезное - тестирование.
Люди предпочитают пробегать глазами текст за минуты, приготовленный за часы...
И все же у отчетности должна быть польза.
Мои проект/тест менеджеры по разному желали получать отчетность. Одни - каждый день, а лучше - каждый час. Другие - по факту окончания тестирования. Кому то хватало списка найденных багов и протестированных задач. Кто-то хочет отчет с графиками и дополнительным доказательством, что все идет по плану. Кому то - достаточно в конце недели письма с парой предложений.
Мне всегда больше нравилось быть наготове всегда - для этого у меня есть своеобразный статус отчет, результаты в котором я подвожу каждое утро на свежую голову. Я уже приводил пример - один из вариантов отчетов с RAG статусом и прочими плюшками. Сегодня я расскажу о своих эвристиках.
Есть несколько правил, которых я пытаюсь придерживаться, когда доношу информацию о своем прогрессе и статусе. Это мое ИМХО накопленное с годами работы в достаточно крупной компании, а потому склонно скатываться к прикрыванию пятых точек. В небольших "семейных" стартапчиках такое может и не понадобиться (хотя тот же Роман Савин в свой книге напоминал, что подтверждать письмами - хороший тон и дополнительное прикрытие).
Мы успеваем?
Это практически единственное, что волнует менеджеров, лидов, начальников. То что вы делали, то что вы собираетесь делать - практически никого не волнует до тех пор пока RAG статус зеленый.
Мы успеваем?... Ок.
Но если статус меняется на желтый или красный? Вот тут то и появляются они - дополнительные вопросы.
Не успеваете?
Что вы весь день делали?
Что вы собираетесь сделать - чтобы сократить отставание?
Эта информация если и не размещается в отчете всегда должна быть наготове.
Статус - каждый день
Каждый день происходит масса вещей, или - не происходит. Но отследить и запротоколировать их нужно если цикл тестирования больше чем один день. Это своего рода слепок дня.
Если не было проблем - ну так и счастье с ним.
Если же тестовая лаборатория заработала после обеда, а новый билд накатили в девять вечера, то успеть прогнать восьмичасовой тест сет раньше десяти вечера не получится.
Хотя опять же всегда найдутся теоретики рождения одного ребенка за месяц силами 12 женщин.
Если не было проблем - ну так и счастье с ним.
Если же тестовая лаборатория заработала после обеда, а новый билд накатили в девять вечера, то успеть прогнать восьмичасовой тест сет раньше десяти вечера не получится.
Хотя опять же всегда найдутся теоретики рождения одного ребенка за месяц силами 12 женщин.
На создание - не более 15 минут
Сейчас я трачу 15 минут на редактирование wiki страницы с вкрапленными фильтрами из Jira и подсчет времени - сколько осталось. Время берется из той же джиры.
Сейчас пытаюсь достичь 5 минутного интервала или сделать отчетность полностью автоматической. Мог бы написать не более пяти минут - но пока сам не достиг, советовать не могу. Честность - мое второе я. Первое, наверное, - скромность )))
На чтение и понимание - не более 5 минут
Буду краток.
Если человек тратит на просмотр ежедневного отчета более 5 минут, значит это не отчет, а спам.
В корпоративной культуре для этого есть специальная папочка - Trash.
Если человек тратит на просмотр ежедневного отчета более 5 минут, значит это не отчет, а спам.
В корпоративной культуре для этого есть специальная папочка - Trash.
Проблема - владелец - дата
У вас проблемы?
Нет?
А если будут?
Собственно любая проблема должна иметь описание, владельца (решатора, координатора, или иного ратора) и дату - когда ожидается выполнение проблемы.
С ходом работы всегда появляется желание слегка улучшить отчет и добавить еще несколько метрик, замечаний, комментариев, ссылок.... Но, к сожалению, с ростом информации уменьшается понятность отчета. Он становится неуправляемо информативным.
Нужно быть настороже. Больше информации - не значит лучше.
Ничто не постоянно.
Отчеты не исключение.
И самый удобный в текущем проекте отчет может не подойти в другом будущем проекте. Возможно, просто не внедрены некоторые практики, чтобы собирать информацию. Или фокус у руководства на другом. Или менеджер не желает получать каждый день что-ты-такое-делаешь-сегодня. Варианты разные. Нужно заранее договориться о формате.
Поймите как Они хотят получить информацию от Вас.
Ничего сложного - просто договориться.
Нет?
А если будут?
Собственно любая проблема должна иметь описание, владельца (решатора, координатора, или иного ратора) и дату - когда ожидается выполнение проблемы.
Отчет стремиться к увеличению ненужной информации
С ходом работы всегда появляется желание слегка улучшить отчет и добавить еще несколько метрик, замечаний, комментариев, ссылок.... Но, к сожалению, с ростом информации уменьшается понятность отчета. Он становится неуправляемо информативным.
Нужно быть настороже. Больше информации - не значит лучше.
Отчет - инструмент и продукт в одном
Еще одно главное, что я всегда держу в голове докладывая о работе: любой документ может быть инструментом (для принятия решений, контроля результатов - что кстати опять ведет к принятию решений) и продуктом (вещью, которой мы продаем процесс, ресурсы, тестирование целиком, свою работу)
Отчет - редкое сочетание, когда документ обязан быть и тем и другим.
Сделайте его красивым.
Отчет живой
Ничто не постоянно.
Отчеты не исключение.
И самый удобный в текущем проекте отчет может не подойти в другом будущем проекте. Возможно, просто не внедрены некоторые практики, чтобы собирать информацию. Или фокус у руководства на другом. Или менеджер не желает получать каждый день что-ты-такое-делаешь-сегодня. Варианты разные. Нужно заранее договориться о формате.
Поймите как Они хотят получить информацию от Вас.
Ничего сложного - просто договориться.
ВИЗИБИЛИТИ
О том, как готовиться к статус апдейту вроде поговорили. Есть еще отдельная ветка телодвижений, не связанных с отчетностью, но - с донесением о том, что ты правильный человек.
В нашей компаниии есть формальный процесс аттестации, который обязателен для всех. Есть несколько категорий, в которые вписываются как задачи на год, так и выполненные работы
1. Польза бизнесу (в нашем случае как мы тестировали: лучше, быстрее, качественнее...)
2. Отношения (как мы строим отношения с коллегами, пользователями, менеджерами опять же)
3. Саморазвитие (что читаем, как используем новые знания)
4. Управление людьми (больше для менеджеров - как оказываем влияние на людей, но тестировщики должны тоже уметь манипулировать разработчиками и начальниками)
Меркантильно? Может быть, но лучше быть на виду, чем получить двойку на аттестации, что не создал канал оповещения для своего начальника (был такой грустный пример на моей памяти).
Один на один
Сильнее, чем поговорить один-на-один, средства рассказать о себе никто не придумал. У нас в компании менеджеры применяют подобное средство и чтобы выслушать подчиненного и чтобы рассказать о наболевшем (чой то я не вижу что ты работаешь - кофе постоянно пьешь, блоги смотришь).
Часто бывает, что рассказать о человеческих недостатках легче кому-то другому, а не тому кто напортачил. В этом случае менеджер - хороший инструмент ))). Он может выслушать и тебя и тех, кто говорит о тебе и собственно стратегия 360 фидбека будет в действии.
Так вот - если начальник не часто спрашивает вас о работе - сделайте это сами.
Доставьте ему удовольствие - сделайте ему one-to-one митинг.
Записывайте ходы: для бизнеса, для людей, для себя
В нашей компаниии есть формальный процесс аттестации, который обязателен для всех. Есть несколько категорий, в которые вписываются как задачи на год, так и выполненные работы
1. Польза бизнесу (в нашем случае как мы тестировали: лучше, быстрее, качественнее...)
2. Отношения (как мы строим отношения с коллегами, пользователями, менеджерами опять же)
3. Саморазвитие (что читаем, как используем новые знания)
4. Управление людьми (больше для менеджеров - как оказываем влияние на людей, но тестировщики должны тоже уметь манипулировать разработчиками и начальниками)
Очень полезно раз в неделю-месяц заняться саморефлексией и записать несколько достижений по этим категориям. Они еще пригодятся на аттестации или для встреч с начальством.
Записывай свои лучшие ходы в свой личный еженедельный отчетик, даже если этого не требуют.
ЗАКЛЮЧЕНИЕ
Первых шагов много. И, конечно же, я не затронул всех тем, связанных с появлением нового тестировщика в новом проекте.
Это и выбор рабочего стола - подальше от кондиционера и поближе к окну.
Это и выяснение - какой сорт пива предпочитает самая симпатичная тестировщица .
Это и поиск прокси, через который можно выйти в гмейл или поднять скайп в обход запретов и сисадминов.
И крайне деликатный вопрос - как все время уходить в отпуск только летом.
Все остальные темы я постарался затронуть.
А если серьезно? Что я действительно не стал обсуждать - это техническую грамотность и изучение новых технологий. Технологии играют значительную, но не самую важную роль (как любят думать разработчики и менеджеры). Технологиям легче научиться, чем тому, что в споре с разработчиком, менеджером или иным сослуживцам вовремя подумать "А ведь он может быть прав". Этому не научишься по книжкам, равно как и тому, что в отсутствии задач, нужно спрашивать, либо догадываться самому - что полезно сделать прямо сейчас.
И еще первые шажки - не всегда заканчиваются летящей походкой. Это и первые шишки и первые грабли и первые раны и первые "убийства" (к сожалению хромающие программисты - не такая уж редкость).
О чем я всегда думаю, когда приходится делать первые шаги это:
На первом месте - не навреди. До тебя тестировщиков не было, и сразу все идеально сделать не получится. Будь скромен, спокоен и настойчив.
К этой мысли я пришел постепенно. А еще то, к той что
Это и выбор рабочего стола - подальше от кондиционера и поближе к окну.
Это и выяснение - какой сорт пива предпочитает самая симпатичная тестировщица .
Это и поиск прокси, через который можно выйти в гмейл или поднять скайп в обход запретов и сисадминов.
И крайне деликатный вопрос - как все время уходить в отпуск только летом.
Все остальные темы я постарался затронуть.
А если серьезно? Что я действительно не стал обсуждать - это техническую грамотность и изучение новых технологий. Технологии играют значительную, но не самую важную роль (как любят думать разработчики и менеджеры). Технологиям легче научиться, чем тому, что в споре с разработчиком, менеджером или иным сослуживцам вовремя подумать "А ведь он может быть прав". Этому не научишься по книжкам, равно как и тому, что в отсутствии задач, нужно спрашивать, либо догадываться самому - что полезно сделать прямо сейчас.
И еще первые шажки - не всегда заканчиваются летящей походкой. Это и первые шишки и первые грабли и первые раны и первые "убийства" (к сожалению хромающие программисты - не такая уж редкость).
О чем я всегда думаю, когда приходится делать первые шаги это:
К этой мысли я пришел постепенно. А еще то, к той что
Тянуть все свои бест практики, метрики, стандарты из одного проекта в другой без подтачивания под конкретный проект и команду бессмысленно и преступно.
Ибо нельзя вставлять в исправно работающие «Жигули» запчасти от «Мерседеса».И детали другого "Жигуля" то не подойдут кстати. Что уж говорить о людях.
Новые технологии, ноухау, привычки отдельных специалистов и самое главное традиции команды - это ли не раз топило стремительные корабли новых процессов новых тестировщиков.
Проект может быть стартапом, может требовать коренных изменений или просто поддержки. Но желание помочь команде - должно быть постоянным.
Удачных шажков - будущих и настоящих.
Комментариев нет:
Отправить комментарий