сложной для меня ситуации (потому что наверное не сталкивался с ней ранее), что документация на проекте от одного аналитика не терпит никакой критики, т.е она не местами некачественная, она структурно или можно сказать стратегически неверно написана, т.е читаешь ее, написанную вроде на русском языке, но не понимаешь, даже на 10 раз прочтения порой. И каждое предложение в документации по сути ребус.
Я тестил документацию на разные проектах, плюс минус понимаю, как и что в доке нужно править, а вот тут вообще непонятно как подступиться, ибо сам факт существования этой документация - большая ошибка, от которой страдает, насколько я знаю, вся команда.
Как бы вы поступили в такой ситуации? Не хотелось бы со всей аналитикой перессориться, но лобби у них на моем текущем проекте очень сильное, могут закидать помидорами тут же))
Постою послушаю ответы) Тоже была в такой ситуации. И проблема не в том, как донести до такого аналитика, что нужно писать не так, а в том, что у него как-то по-другому устроены мозги, и он просто не может иначе. Мы пытались для начала попросить уделять больше внимания структурированию задачи, разделению её на части. Но от этого местами становилось только хуже. А потом этот аналитик уволился (не знаю, связано ли это было с жалобами), и проблема решилась сама собой. Но вот как бы можно было с этим работать, интересно.
даа, вот я об этом и говорю, что человек мыслит нестандартно и вообще не разумеет, а что тут непонятного?)
1. Проверить поднимался ли это вопрос раньше Собрать инфо Посмотреть Отжать Отложить- пригодится позже 2. Оценить обстановку- аккуратно спросить разных вовлеченных людей мнение . Запомнить кто за кто против кого можно перетянуть 3. ПОдготовить почву - начать капать вежливо и методично легкими замечаниями и упоминаниями 4 Одна или несколько решительных встреч обсуждений- быть готовым и ярко ,обоснованно и как принято в данной компании показть , почему и как надо менять . Лучше договориться . Но можно и нажать на кое какие точки 5 Закрепить успех . Упомянуть как стало хорошо всем ( не только вам) и особенно боссу Сделать это эмоционально и наглядно Поддержать отзывами коллег Но надо ли это все? Те затраты и резльтат хорошо заранее оценить .. просто впечатление от документации токо вершин айсберга
Я один раз так сказанул на проекте будучи разрабом, только не плавно, а прямиком сразу директору, что тут много что улучшать и править весь говнокод, но меня решили уволить Больше так делать не буду)
Разыгрывать офисные партии- отдельная большая тема . Это ж как и любое сложное дело требует подготовки, правильных шагов, гибкости и многого другого Конечно , не надо будить .. и бросать..и тыкать.. и дергать за усы без правильного подхода- получится, скорее всего , не круто
Так можно на ретро сказать просто - была вот такая проблема. Если команда согласна - они поддержат.
У технической документации есть ряд общепринятых свойств, по которым можно считать её качественной или наоборот. Кроме того - документацию тоже можно(нужно) тестировать и на неё можно писать баги. В том числе баги можно писать не на конкретный участок документации, а сообщить о системной ошибке в документации приведя несколько примеров. Прям вводишь в гугл "тестирование проектной документации" - парочку годных статей выдаст точно.
Когда ты видишь регулярные баги от одного разработчика - что ты обычно делаешь?)
Делаю специальный чек-лист "типичные баги от Лёши", раздаю другим QA в отделе, пингую Лёшу что он з***л и сообщаю проект-менеджеру. В моей практике эффект возымел только чек-лист.
Обсуждают сегодня