?

Log in

No account? Create an account

psilonsk


Блог об управлении проектами


Previous Entry Share Next Entry
Вопрос из зала: плохо формализованные задачи в ИТ-проекте
psilonsk


Одна милая барышня прислала письмо с проектным вопросом. Предлагаю помочь барышне добрым экспертным советом.

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

Работаю тестировщиком сейчас в одном проекте, пишем десктоп-приложение. Создаются задачи на 2 недели, пока разработчики разрабатывают, я пишу тест-кейсы. Когда спринт закончен, они отправляют его на тестирование, и тестирование делает другой человек по моим тест-кейсам. Для меня схема слегка странновата, но у них так уж сложилось и как-то работает.
Проблема в следующем: задача содержит фразы типа "надо разработать загрузку фото", и там указывается, где это фото должно быть. Как это должно выглядеть не описано, устно говорят: "У нас везде такие загрузки используются". Но по мне загрузка, скажем,
PDF и загрузка фото - разные вещи. Ну и плюс в задаче было много информации, которая, как опять же оказалось при личном общении, будет сделана в другом спринте, просто забыли обновить.
На мое предложение описывать как должно быть, ПМ ответил: "у меня нет времени, ты всегда можешь все спросить". Получается, не спросила - сама виновата, что не поняла. Но! Что-то может измениться уже после того как задача в спринте и мы ее обсудили...

Чего мне делать?
1. Продолжать давить на ПМ каждый раз, но сегодня я уже получила: "твои замечания не имеют смысла, у меня нет времени" - испорчу отношения.
2. Идти к начальнику и говорить о проблеме с описанием задачи - не знаю о возможных последствиях.
3. Продолжать писать тест кейсы и дождаться чтобы разницу увидел человек, который проверяет - я буду виновата, что не спрашивала.
4. Ходить по каждому вопросу или собирать все в один и тратить один или два дня ПМ, пока он мне не объяснит требования к каждой задаче и ждать, пока ему надоест, - мне надоест первее :(

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




Ждем ваших умных комментариев и советов.)


promo psilonsk february 12, 2015 18:07 17
Buy for 100 tokens
Ранее в сериале: История первая: договор Ариадны История вторая: лыжи, смоктульки и чаевые История третья: мертвец и розетка ​*** — Послушай, Леша, послушай меня, милый мой друг. Ты же менеджер проектов, так? Ты же не дебил, правильно? Я тебе на пальцах объясняю, а ты понять не можешь.…

  • 1
(Deleted comment)
А можно по подробнее?
1. в чем выражены ее незнание и низкая квалификация?
2. что именно она должна искать в интернете?

Просто сам работаю в сфере разработки ПО и этот вопрос интересен.
В нашей команде мы решаем его сейчас через сценарии BDD и TDD и экспертную комиссию со стороны заказчика. Т.е. пока задача полностью не описаны и заказчик не согласен с принципом ее реализации и проверки результата - за нее даже не принимаются.

(Deleted comment)
(Deleted comment)
(Deleted comment)
(Deleted comment)
(Deleted comment)
(Deleted comment)
Для начала неплохо было бы понять, этот способ постановки задач принят в компании за норму и так работают все, или это прикол конкретного ПМ?
Потому что если так "исторически сложилось", то барышня будучи новичком и рядовым тестировщиком не сможет к сожалению перестроить существующие процессы в компании.

Еще очень странно, что в ситуации когда задача поставлена кое-как на бегу, при отсутствии формального тз, в провале виноват исполнитель. Обычно ответственный за свой продукт все-таки ПМ, и в случае проблем с качеством или сроками спрашивают с него, а потом уже с исполнителей. Что и делает его кровно заинтересованным в грамотной постановке задачи и письменных доказательствах оного :)

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

Как вариант: ввести практику утверждения тест-планов у РМ, аналитика. И пользоваться ими как поводом для общения и формализации требований.

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

Если отказываются утверждать, возвращается к дискуссии "из каких документов я могу это узнать?"

Edited at 2014-07-22 04:35 am (UTC)

Когда информация "обтекает" участников проекта -- это всегда вина PM. Хотя тут также видны проблемы не очень опытного тестера.
Что могу посоветовать от себя:
1. Записывать, записывать и еще раз записывать. Все обсуждения на любых встречах вносить в склеротичку. Не стесняться переспрашивать. Фразы "Я правильно поняла..." и "Так что конкретно мы решили по этому вопросу" должны стать вашими любимыми. Требуйте четких формулировок.
2. Все вводные для написания тест-кейсов оформлять электронным письмом и рассылать всем заинтересованным участникам.
3. Требовать, чтобы о все изменениях уведомляли письменно
4. Рассылайте тест-кейсы с вводными (с учетом изменений) всем заинтересованным сторонам.
5. Если требуется что-то уточнить -- высылайте письмо с вопросом. Не реагируют -- звоните.
Даже если предположить, что вы хороший тестировщик, подобные действия часто плохо сказываются на карме в конторах, где царит разгильдяйство. Ибо люди не любят отвечать за свои слова и подписываться под конкретными обязательствами. Если вы плохой тестировщик, то рискуете всех задолбать дурацкими вопросами. Но в любом случае, документирование -- это меганавык для проекта.

1. В чем неопытность тестировщика, на ваш взгляд?
2. "Требовать о письменном уведомлении" - как лучше это делать, напрямую у пм? Через начальника?

1) собирать вопросы в пакеты, раз в один-два дня присылать их постановщику задачи. Письменно! Обсудить можно и устно

Вообще писать как можно больше
2) включить зануду. На каждый ответ "везде" спрашивать "где именно?" как правило ответа не будет но будет указан "аншпрехпАртнер" - человек, который может может это сказать. Вообще, никогда не уходить после ответа "не знаю" или общего плана, всегда добиваться или конкртики или указания Ansprechpartner, если никто не указан - идти к начальнику и говорить: неизвестно кто "партнер по переговорам" по этому вопросу, помогите. Для начальника это красная лампочка: в проекте есть кусок за который никто не отвечает.

3) писать кейсы как есть и оправлять их на проверку. Пусть отвечает тот, кто под ними подписался

4) молиться. Германия - один большой бардак, германское АйТи - еще больший бардак, а если оно еще и на SCRUM то в этом бардаке все уже заживо погребены, просто не знают об этом. Ситуация, в которой "Обязательно спрашивай, а то сам виноват, только не спрашивай меня больше, достал уже!" - к сожалению, абсолютно нормальна. Настолько, что даже жаловаться на нее некому, начальник не поймет
- Тебе же сказали - спрашивай если что непонятно!
- Вот я и спрашиваю, мне непонятно!
- Нет, это неправильное непонятно , это надо понимать, ты спрашивай если в самом деле что-то непонятное непонятно!

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

4 и 5 порадовали :)) про вопросы отлично конечно, но первый круг - а как это должно быть сделано, если скрины в задаче не предусмотрены для новой фичи? Ответ, а вот посмотри там загрузку файлов, тут также. Прошло какое-то время, тестировщик покапался в функционале, пошел 2ой круг и может быть третий. И получается тестировщик таким жужжащим существом с дурацкими вопросами.

Комбинировать 3 и 4. Сначала больше 4, потом заметит, что необходимость в 4 отпадает и вариант 3 уже хорош.

ПМ прав: не рентабельно расписывать всё. Расписываем в первую очередь то, что повторяется; во вторую то, где цена ошибки высока. По остальным кейсам сотрудники не должны бояться ошибки, ибо лечение дешевле, чем профилактика. Синхронизируем интуицию с командой и ошибаемся редко.

Границу высокой-низкой цены ошибки определяет менеджер.

Что значит расписываем то, что повторяется? Я считаю при повторении можно указать ссылку и отличия. А если фича новая, то расписывать все и подробно

Уточняющий коммент от барышни

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

Re: Уточняющий коммент от барышни

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

писать кейсы в общем виде с предложением возможных популярных вариантов

Левый тестировщик как по ним будет что-то тестировать?

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

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

На сколько я знаю, в скраме проводятся ежедневно короткие митинги, чтобы все были в курсе, что делается на проекте. Если они не проводятся, то договориться с ПМ о ежедневной 10минутке для вопросов, раз он такой занятой; узнать, кто знает больше о проекте и тех.решениях и у него спрашивать "а есть ли такая функциональность для загрузки, которую можно перетянуть в другое место".

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

  • 1