|
Администратор
Регистрация: 18.02.2010
Сообщений: 17,013
|
http://habrahabr.ru/post/122065/
↓↓ часть 1
Корпоративный троллинг. Часть первая
В коммерческой деятельности одним все время что-то нужно от других. В проектном бизнесе вы жаждете втюхать свои услуги. Вам нужно получить прибыль. Заказчику тоже много чего нужно. Но, независимо ни от чего вам нужно продать услуги и получить за них деньги. На каждом этапе вам будут оказывать сопротивление. Сегодня я начну рассказ о том, кто и как будет оказывать вам сопротивление и что вы можете сделать для того, чтобы этому противостоять.
В общих чертах проект в ИТ состоит из следующих этапов. Сначала вы узнаете о потребности кого-то в чем-то (или создаете эту потребность). Потом вы третесь возле заказчика, всячески облизывая его и склоняя в сторону откровенного разговора. Я намеренно выношу за скобки коррупционные сделки и буду рассказывать только о сделках в рамках закона.Когда клиент созревает для встречи, вы устраиваете шоу, в ходе которого продается идея и рисуется картина прекрасной жизни, которая наступит после внедрения вашего решения. Потом контракт и аванс. Потом обследование и долгая нудная работа по проектированию. Потом сдача проектных документов. Потом реализация и запуск решения. Потом ввод в действие. Каждый этап закрывается актом, на основании которого вам на счет падает копейка. Вот такой бизнес. Конечно, я утрирую, и иногда все может быть наоборот. А иногда — и шиворот навыворот.
Итак, займемся классификацией троллей и их приемов. Сегодня — формальный троллинг. В другой раз троллинг очный.
Какие бывают тролли
Троллинг возникает на каждом этапе, где вам от заказчика нужна подпись на акте о выполненных работах. Также троллинг возникает в ходе внедрения и даже в ходе предварительной презентации. Потому что тролли бывают разные.
Всего британские ученые выделяют три разновидности троллей.
Тролли — жертвы. Это те бедолаги, которые страдают от вашего появления. Они теряют влияние, работу. Или наоборот, им приходится работать, если до этого они пинали балду. Любые изменения люди принимают в штыки. Это есть научный факт. При этом одни затыкаются и молчат в тряпочку, а другие начинают троллить. Вычислив таких обиженных, вы должны их гасить при каждом удобном случае. Если они сидят на одном совещании с вами, то не допускайте, чтобы они сидели рядом с боссом. Втискивайтесь между боссом и троллем. Ищите логические несостыковки в словах тролля и указывайте ему на них. Подвергайте сомнению его компетенцию, насколько это возможно по контексту. Главное, не перегнуть палку.
Наиболее злобные тролли должны выноситься из проекта. В крайнем случае пишите официальные письма. Потому что убыток от действия троллей колоссальный. Ниже я расскажу о том, как производится троллинг и вы сами все поймете.
Тролли-киллеры. Это специально выделенные сотрудники, готовящие почву для появления «босса в белом», который будет предлагать вам заведомо невыгодные условия или попросту отжимать бесплатную работу или скидку. Вопросы художественного отжима достойны отдельного описания, так что оставим это удовольствие на потом.
Тролли — выскочки. Как правило, это карьеристы, которые не брезгуют использовать любую возможность для самопиара. Если человек толковый, ему можно и подыграть. Когда он смекетит, что вы работаете на него, он так же плавно начнет вам помогать. Если он дебил, что наиболее вероятно, то вам придется его припугнуть, прилюдно унизить и дать понять, что ему вас не переиграть. В крайнем случае он так же должен выноситься из проекта, как и тролль-жертва.
Виды формального троллинга
Проще всего работает формальный троллинг. Например, в ходе согласования документов и в ходе приемки системы. В документах пишется обычно всякая лажа, докопаться до которой особого ума не надо. Вот для примера, самые заметные грабли.
Любой, каждый, все. Эти три магических слова не должны встречаться в ваших технических документах. Ищите и давите их, если вы не хотите, чтобы тролли праздновали легкую победу! Написали «выбирете любой объект». Тролль выберет именно тот, который не будет отвечать заданным условиям. И будет абсолютно прав. Так же его не обломает проверить «каждый» элемент. Если хотя бы в одном не будет наблюдаться сходства, то ваша фраза является формально ложной, а значит, можно смело заносить это в протокол, без лишних деталей. Большой босс не станет копаться в деталях, а просто не подпишет акт и оставит вас без денег.
Вал замечаний. Метод относится к изматывающим тактикам. Его применяет тролль-киллер, который может потратить неделю на то, чтобы подготовить сотни замечаний к вашим документам. Тут фишка в том, что для отработки каждого замечания вы тратите значительные ресурсы. А отрабатывать их вы обязаны. Даже если нужно всего лишь дать объяснения, то вам нужно их написать, составить общий реестр, не забыть подготовить протокол отработки, сопроводительное письмо. Иногда приходится выдергивать специалистов, которые уже могут быть заняты на других проектах или могут быть в командировке. В итоге вы можете просесть по срокам, что будет являться формальным поводом вас послать.
Бесконечный цикл. Вы отрабатываете все присланные замечания и думаете, что победили. Но тролли подготовили вам еще кое-что. Документы пересылаются на согласование троллю из другого отдела под предлогом сложного внутреннего регламента, а тот генерит еще пару десятков замечаний. Вы отрабатываете и их. Тогда первый тролль говорит, что вы внесли изменения в исходный документ, о которых он ничего не знает. И снова начинает вычитывать и генерить новые замечания. Все продолжается ровно до тех пор, пока вы не просрочите очередную отработку, после чего вас радостно посылают.
Во-первых, сразу подготовьте регламент работы по замечаниям, затвердите его у босса. Чтобы заказчик собрал все в одну кучу, в стандартную форму (например, в табличку) и отправил вам для отработки. Это исключит циклы и дублирование замечаний.
Далее вы должны назначить анти-тролля, который будет планомерно докапываться до каждого замечания. Где нет конкретики — нафиг. Где демагогия — нафиг. Из всей кучи присланных замечаний выбирайте только те, где четко написано что нужно изменить. Остальные отклоняются. В 70% случаев от вас отстанут. Но если на той стороне окопался тролль-жертва, готовьтесь к смертельному поединку. Он не успокоится и будет все равно долбить вас замечаниями. В ряде случаев нужно привлекать тяжелую артиллерию из тех, кто заносит бабло, чтобы тролля-жертву отстранили от участия в проекте.
Согласитесь, все это было бы очень грустно, если бы не было так весело. В конце концов, это такая же игра, как и многие другие, в которые играют взрослые дяди и тети.
http://habrahabr.ru/post/122148/
↓↓ часть 2
Корпоративный троллинг. Часть вторая
Сегодня мы разберем разновидности противодействия, которые встречаются при очных мероприятиях — на презентациях и переговорах. Конечно, трудно охватить одним махом обширнейшую сферу черной риторики, черного пиара и прочей черной мерзости, которая сопровождает любое наше даже самое благое начинание. Но хабралюди народ опытный, информацию искать обученный. Как говорится, хороший инженер не обязан все знать, но он должен уметь быстро добывать необходимые знания. Сам я не являюсь гуру ни в переговорах, ни в риторике, но имел опыт общения с настоящими мастерами своего дела, которые в Хабр писать никогда не станут, даже если знают о существовании этого ресурса. Мне кажется, что этот опыт, обобщенный и очищенный от эмоций, будет многим интересен.
Презентация
Давайте представим, что вам поручено презентовать некую систему, которая планируется к внедрению в некоей организации. Перед вами сидят будущие пользователи, руководители этих пользователей и, может быть, на огонек забредет Сам (Который Дает Деньги). Самого окучивают обычно продавцы, но они могут привести его показать товар лицом. То есть, авторитетного человека в галстуке перед экраном с веселыми картинками.
Допустим, вы сумели возбудить аудиторию неизбежностью грядущих перемен. Это достигается обычно наглядными примерами, приближенными к жизни команчей пользователей. Когда люди начинают примерять будущее лично на себя, они начинают думать. У них появляется неприятное чувство. И у некоторых может возникнуть желание, чтобы вы и ваша компания исчезли бы с горизонта и вообще больше не появлялись бы никогда. И тогда начинается противодействие.
«У нас этого никогда не будет»
Самая часто встречающаяся фраза. Вариации: «30 лет работали без вашей системы и ничего», «У нас уникальные методы (околачивания груш)». Стопроцентного рецепта здесь нет и быть не может, потому что сама формулировка абсурдна. По сути это прием софистики. Точно так же можно сказать, что «я прожил 30 лет, и еще 300 проживу». Из первого совершенно не следует второе. Главное, не дрогнуть, когда вам говорят такое. И еще запомните того, кто это сказал первым. Перед вами Тролль-жертва (см. предыдущий пост). Скорее всего, это руководитель среднего звена, который плотно сидит на сопровождении замещаемой системы. Или тот, чьи кадры будут выдернуты для сопровождения вашей системы. Или просто уважаемый всеми сотрудник, который решил лишний раз поднять свой авторитет.
Познакомьтесь с тем, кто утверждает подобное. Вы — само дружелюбие и искренне желаете узнать причины столь категоричного заявления. Как только вам назовут причины, вы сразу извинитесь, подхватите ноут подмышку и покинете почтеннейшее собрание. Как правило, клиент начинает вилять и вы плавно переходите к следующим вопросам повестки. Но иногда начинается «исторический экскурс». Бойтесь его как огня! Потому что он гипнотизирует других «старожилов» и как только вы выдерните их из сладких грез, они вас возненавидят. И вашу продукцию заодно.
Исторический экскурс
Очень опасный артефакт. Начинается как безобидная история из жизни. «30 лет назад начали мы внедрять подобную систему...». И далее следует печальная история внедрения. Которая легким росчерком ставит крест на всех ваших аргументах в пользу внедряемой системы. Кто вы, и кто этот всеми уважаемый человек? Проблема еще в том, что вы же не можете сказать представителю заказчика, что дело не в «плохой» системе, а в его кривых руках (или в том, что 30 лет — это целая вечность в ИТ). Так или иначе, исторические параллели на презентации очень опасны. Особенно, если вы молоды и не можете рассказать, как вы в 1986 году писали управляющие алгоритмы для какого-нибудь марсохода. В то же время, в ходе интервью подобные истории, напротив, представляют большую ценность. Но это уже совсем другой разговор.
Вас спасет регламент. Попросите перенести историю на после презентации, скажите, что у вас еще 180 крайне интересных слайдов и демонстрация прототипа на сладкое.
Внимание, вопрос!
Вопросы без вопросов также направлены на переключение внимания аудитории с темы вашей презентации на что угодно другое (обычно на личность «вопрошающего»). Человек поднимает руку: «Можно вопрос?». После вашего разрешения начинается речь в стиле «исторического экскурса».
Самое лучшее, если вы сразу говорите, что сессия вопросов и ответов будет в конце презентации. Но иногда (и чаще всего) вы должны приветствовать вопросы аудитории в ходе презентации. Если началась «речь» под видом вопроса, не стесняйтесь как можно раньше поинтересоваться, в чем же вопрос. Можно даже прервать выступление через минуту. Верните контекст назад. Вам задают вопрос, вы готовы отвечать и ждете вопроса.
Черная риторика
Миллион приемов разной степени жестокости. Если вам не повезло, и вам попался искушенный в черной риторике оппонент, срочно вызывайте подкрепление! Если рядом есть старший товарищ — сейл, руководитель проекта и т.п., адресуйте вопросы ему. Если вы одни перед троллем, бог вам в помощь. Или качайте соответствующий скилл. Погуглите литературу и начинайте тренироваться. Как правило, базовых приемов противодействия хватает на 99% троллей-самоучек. А если вдруг вам попался тот самый 1%, то это уже, скорее всего, заказ. То есть, выпустили тролля-киллера, и решение проблемы лежит в политической области.
Для примера, вот приемы из личной практики:
— «Ваши данные неверны, исследования компании Х это подтверждают» (про графики или цифры). Пока вы будете оправдываться, доказывая, что ваши источники достоверны, все запомнят только то, что вы гоните лажу.
— «А вы лично участвовали в проектах по внедрению вашей системы на таких (уникальных) предприятиях как наше? Как без знания нашей (уникальной) специфики вы вообще можете рассказывать нам как нам делать нашу работу?» Тот же прикол, что и в предыдущем пункте.
— «А вы знаете о том, что...» Далее следуют какие-то внутренние договоренности, о которых вы, скорее всего, слыхом не слыхивали. Это пример использования ссылочного, или рефренсного влияния. Любимый трюк всех начальников. «Да ты не знаешь чего там наверху творится!» «У тебя нет всей информации, чтобы так говорить!» И т.п.
Тема поистине неисчерпаема, а опыт и навык противодействия можно приобрести только в бою.
Переговоры. Художественный отжим
Приведу всего два простейших приема, которые работают и часто срабатывают на переговорах со специалистами. Что там происходит между сейлом и заказчиком тайна великая есть и, наверное, это предмет другого блога.
Злой эксперт и добрый босс
Цель мероприятия — вывести вас из равновесия путем оказания давления. Для этого приглашается тролль-киллер, который начинает докапываться до каждого слова, до каждого документа, ругаться, возмущаться и часто вообще терять адекватность. Ваш проигрыш — когда в ответ на очередной выпад вы теряете спокойствие и начинаете реагировать соответствующим образом.
Любой воспитанный человек ищет выход из конфликтной ситуации. И выход вам будет предложен в виде «доброго и мудрого босса». Который усмирит разошедшегося сотрудника, предложит вам кофе с коньяком и некоторые условия выхода из кризиса. Которые до этого вам казались неприемлемыми, а теперь кажутся чуть ли не единственным спасением.
Что делать? А ничего! Не теряйте самообладание, держитесь линии партии. Это торговля, и вы должны иметь некоторый люфт. Если вас не снабдили инструкциями о том, где можно просесть, а где нельзя — ваш начальник лох непрофессионал. Сколько уже из подобных побоищ спецы в подоле приносили месяцы лишней бесплатной работы — не счесть. Пожалуйста, заставьте ваших боссов дать вам карты на руки. Это же их работа, в конце концов.
Встречается даже вариация стокгольмского синдрома, когда спец приходит с переговоров и начинает гнобить своих же, превознося личные качества заказчика, к которому до сих пор теплых чувств не питал совершенно. Это говорит о том, что на той стороне работает настоящий мастер. Такие часто встречаются среди государственных чиновников. Они оттачивают мастерство годами, ничем другим кроме отжима и троллинга не занимаясь.
Телеграмма из Центра
Вариант описанного выше приема при отсутствии злого спеца. Практикуется средними функционерами и управленцами, которым по должности не позволяется иметь личного шофера и ручного тролля-киллера.
В первой части схемы давление оказывает самолично представитель заказчика. В ход идет весь доступный арсенал, включая приемы ссылочного или рефренсного влияния. Обилие ссылок на «высшие силы», «корпоративные стандарты», «генерального директора» или «Кремль» говорит о приближении Фазы Два.
Когда вы уже полностью осознали свое ничтожество и сидите с поникшей головой, следует Звонок Большого Босса. С изменившимся лицом представитель заказчика выбегает из кабинета, и через несколько минут возвращается просветленный. Дескать, «я объяснил Самому нашу плачевную ситуацию, радел за дело, выгораживал вас как мог, и Сам решил даровать милость, но при следующих условиях...».
В отличие от первого варианта вы можете в Фазе Один покаяться во всех грехах, отстегать себя плетьми, но не давая никаких обещаний. Можно также иметь жалкий потрепанный вид (см. фильмы с Вуди Алленом). Но Фазу Два вы должны встречать бодро и независимо и не идти ни на какие уступки, помимо запланированных. Более того, удачно разорванный шаблон позволит вам, наоборот, отжать некоторые условия, так как представитель заказчика не может выйти из собственной игры.
Заключение
В данной теме осталось еще разобрать приемы, которые наблюдались при сдаче результатов работы (показ системы или сдача документации). Так что есть задел для третьей части.
http://habrahabr.ru/post/122237/
↓↓ часть 3
Корпоративный троллинг — 3, или сдача работ без лишних забот
В предыдущих статьях (первая, вторая) мы бегло и в шутливой форме прошлись по примерам противодействия, которое оказывают нам сотрудники заказчика на различных этапах проекта. Сегодня предметом рассмотрения будет сдача работ, и мы подойдем к этому этапу во всеоружии, чтобы ни один тролль не прорвался. Получилось много букв, но, надеюсь оно того стоит.
Сдача результатов работы является одним из самых драматических этапов проекта. Человеко-месяцы, потраченные на разработку, отладку, тестирование и внедрение вашего решения, не должны быть потрачены зря. Если сдача работ поручена вам, то ваша роль в команде весьма значительна, а доверие руководства велико, даже если начальники вам этого никогда не говорили. Облажаться на сдаче работ иногда означает конец вашей блистательной карьеры. Так что лучше этого не делать.
Процесс приемо-сдаточных испытаний должен быть строго формализован. Всем понятно, что в конце этого процесса должен появиться протокол и акт, на основании которого выпускается приказ о переводе системы в опытную или промышленную эксплуатацию. Акт также является формальным поводом для выставления счета на оплату очередного этапа проекта.
В этой статье я без лишних шуток (какие уж тут шутки!) и максимально последовательно (ну, для блога, конечно) опишу процесс сдачи проектных работ. Разумеется, многие вещи опытным коллегам покажутся очевидными. Пусть. Зато менее опытные коллеги или желающие примерить ответственную роль сдающего на себя найдут эту публикацию полезной и познавательной.
Направления троллинга в ходе испытаний
Вы не представляете, сколько людей заинтересовано в вашем провале! Кто-то хочет доказать свою правоту насчет ваших умственных способностей, кто-то хочет оттянуть сроки, кто-то мечтает о штрафных санкциях, кому-то нужно новую резину на BMW… В подобных случаях в комиссию подсадят тролля-киллера (см. первый пост). На данном этапе есть три направления троллинга, с которыми приходится иметь дело:
Формальная приемка. Тролль тыкает в ТЗ, где написано что-то вроде этого: «система должна иметь архитектуру клиент-сервер». Вам требуется показать, как пункт закрывается. А вы забыли включить в пояснительную записку к техпроекту строчку «Система имеет архитектуру клиент-сервер» или с перепугу не смогли ее найти. Потратьте время, прочешите все разделы ТЗ и найдите нужные строчки.
Ошибки в тестах. При формулировании тестов избегайте возможности намеренного неверного истолкования. Например, вы пишете, «Из списка пользователей Оператор выбирает любого пользователя». Тролль выберет из списка системного юзера или админа, под которыми тесты работать не будут. Или вы пишете «Отобразились свойства всех объектов». Тролль ткнет в тот объект, свойства которого не отобразились. А вы имели в виду «всех требуемых объектов», но поезд ушел, и вы получаете страшное замечание «Свойства всех объектов не отображаются».
«Крайне важные замечания». Когда пушки основного боя отгремели, начинается разбор замечаний на критические и не критические. Критические будут у вас костью в горле, они мешают подписанию акта. Поэтому тролль будет пытаться сделать каждое замечание критическим. Включается весь имеющийся пафос, привлекаются авторитетные товарищи, кивающие головами, и прочий цирк с конями.
А теперь рассмотрим то, что нам потребуется, чтобы избежать описанных неприятностей при сдаче работ.
Программа и методика испытаний
Документ ПМИ, или программа и методика испытаний, на мой взгляд, более важен, чем даже ТЗ. От качества этого документа зависит половина, если не две третьих успеха испытаний.
Требования к содержанию документа описаны в разделе 2.14 ГОСТ РД 50-34.698-90, также известного как Настольный Стандарт Техписателя. Что должен содержать данный документ:
Полную формальную часть по ГОСТ (объект и цель испытаний, объемы и условия испытаний и т.п.). В итоге после прочтения этих разделов любой член комиссии, даже если он в проекте до сих пор не участвовал, должен понять, что сдают и какова его лично роль во всем этом.
Проверку комплектности всего и вся — документации, дисков, количества передаваемых копий и т.д. Соответственно, к испытаниям все это должно присутствовать физически. Цель — закрыть формальные требования ТЗ и договора в части поставки.
Описание того, как именно проводятся тесты. Будете ли вы скармливать системе реальные данные с физических датчиков или подсунете тестовые файлы или эмулятор? Система будет управлять реальным объектом или достаточно посмотреть логи, где написано о том, что она делала то-то и то-то? Пользователь должен торжественно восседать в диспетчерском зале или можно ограничиться ноутбуком в офисе?
Высокоуровневые тесты системы. Детальность может быть разной, в зависимости от заказчика. Встречаются и общие тесты, и тесты с пошаговыми инструкциями. Цель у тестов простая: когда пройден последний тест вы должны закрыть все без исключения функциональные требования ТЗ, а также отметить тот факт, что в эксплуатационных документах есть требуемая информация (то есть, они годны к работе).
Сценарий тестирования. Тесты должны располагаться в нужном вам порядке, чтобы минимизировать время испытаний и лишние вопросы. Например, если вы проверяете прием, перевод и увольнение сотрудника в кадровой программе, то пусть сценарий будет именно таким — вы принимаете кого-то на работу, потом его же переводите, потом его же увольняете, чтобы ни пришлось каждый раз заводить нового сотрудника и тратить на это время. Или другой пример. В одном из тестов вы должны проверить резервное копирование и восстановление системы. Если испытания идут несколько дней подряд, разумнее было бы запланировать тест на создание резервной копии на конец первого дня. Тогда не пришлось бы дожидаться окончания длительной процедуры. А восстановление можно запланировать на предпоследний день. Перед восстановлением можно проделать жестокие тесты, наподобие эмуляции аварийного выключения, потери журналов и критических файлов (если это требуется испытывать, разумеется). Сейчас сказанное кажется очевидным, но почитайте реальные документы, чтобы убедиться, что это очевидно далеко не всем!
Протокол испытаний
На основе тестов ПМИ вы должны подготовить протокол испытаний. Протокол будет являться документом, подтверждающим то, что ваша система выполнена в соответствии с ТЗ, о чем делается соответствующая запись в акте. Не доверяйте подготовку протокола никому другому, если не хотите иметь бледный вид перед комиссией. Обычно протокол является «копипастом» из ПМИ, так что его подготовка много времени у вас не займет.
Протокол испытаний состоит из общей части, таблицы тестов и списка замечаний.
Таблица, в которую заносятся результаты тестов, может состоять из следующих колонок:
Сквозной номер (в удобном вам формате). Например, Номер_теста.Номер_шага.
Действия оператора. Что делает оператор, для того, чтобы получить результат. Убедитесь, что формулировки исключают злонамеренное неверное толкование.
Ожидаемый результат. Простыми словами описанный результат действий оператора, который можно проверить (пощупать, увидеть, унюхать). Например: «Зажглась зеленая лампочка на верхней панели», «В списке пользователей появился новый пользователь», «На экране отобразилось предупреждение системы о неверно введенном пароле», «В системном журнале X появилась запись Y». Убедитесь, что формулировки максимально конкретные и исключают злонамеренное неверное толкование. Помните также про слова, являющиеся кормовой базой для троллей: «любой», «каждый», «все», «никакие» и т.п.
Пункт документации (например, Руководства пользователя), в котором дано подробное описание выполняемых действий или закрывается нефункциональное требование ТЗ. Наличие этого пункта позволит убить сразу двух зайцев. Во-первых, вы задокументируете то, что все, что надо отражено в проектной документации. Во-вторых, вам не придется подробно расписывать действия оператора, так как (внимание!) к тестам допускаются сотрудники, соответствующие требованиям технического проекта, в которых вы написали, что они должны пройти такие-то курсы и быть знакомы с эксплуатационными документами.
Пункт или пункты ТЗ, закрываемые на данном шаге. Сумма по колонке должна дать все (именно все, а не только функциональные!) требования ТЗ. Именно поэтому в протоколе будут «тупые тесты» на проверку комплектности документации, на то, что программа написана на java и база данных Oracle DBMS является реляционной (тыкаем пальцем в соответствующий раздел документации).
Решение комиссии. Нужно настаивать на следующих решениях: «Пройдено», «Пройдено с замечаниями», «Не пройдено», «Не тестировалось». Других записей тут быть не должно. Запись «Не тестировалось» делается для тестов, проводить которые комиссия не захотела или провести их физически невозможно на момент проведения испытаний. Например, они решили не выдергивать узел кластера из розетки. Лучше, чтобы таких записей в протоколе не было, чтобы не появилась лишняя возможность для троллинга.
Комментарии. Если тест пройден с замечаниями, тут должен стоять номер замечания. Все замечания заносятся в приложение к протоколу в свободной форме. Можно указывать номер теста, в ходе выполнения которого возникли замечания. На большее вам банально не хватит времени. Если решение комиссии «Пройдено», постарайтесь ничего не писать в колонке «Комментарии»
Генеральная репетиция
Без нее нельзя. Только так вы можете отловить все шероховатости в тестах, выявить тесты, крадущие время и тесты, результаты которых сомнительны. Помните, что визуальная составляющая должна быть безупречна. Постарайтесь забить в систему данные, которые выглядят натурально и похожи на то, с чем имеет дело клиент. Проследите, чтобы имена пользователей и другие поля не содержали ненормативную лексику (любимая шутка внедренцев и программеров). Эти «шуточки» иногда действуют на комиссию как красная тряпка на быка.
Не бойтесь переписать ПМИ с нуля. Один раз мы пожалели время и перекомпоновали тесты вместо того, чтобы переписать их. В итоге мы просто успокоили сами себя, не изменив общей плачевной картины. За что и огребли.
Если вы сдаете вдвоем, гоняйте тесты вместе. Приглашайте коллег, пусть они придираются, изображая из себя комиссию. Потраченное на эти игры время в итоге позволит всем вам получить деньги от довольного заказчика.
Эффективный дуэт
Оптимальной командой для сдачи является пара из внедренца (или программиста) и бизнес-аналитика (консультанта).
Внедренец (программист):
работает с системой, демонстрируя виртуозное владение интерфейсом
отвечает на технические вопросы
Аналитик (консультант):
говорит о системе с заказчиком, ведет беседу
отвечает на общие вопросы
ведет протокол
пинает под столом внедренца (программиста)
Такая бригада позволит реализовать прием, который можно назвать «передача микрофона». Если программист вдруг наступил на багу, консультант может дать ему подзатыльник и быстро заболтать заказчика, негодуя по поводу чьих-то кривых рук. Эффект будет как в цирке. Заказчик посмеется про себя и тут же подумает, что он-то не клоун и руки-то у него попрямее будут.
Точно так же, если консультант скажет глупость, а заказчик нахмурится в ответ, программист может с лицом оскорбленной невинности продемонстрировать очередную фишку системы и тогда заказчик проникнется к нему симпатией, так как поймет, кто тут настоящий профи, а кто клоун в галстуке.
В особенно напряженные моменты можно устроить дружескую перепалку, разрядив тем самым обстановку и отведя внимание аудитории от не совсем корректной работы системы.
Не зря же западные «айтишные евангелисты» любят работать парами.
Процесс пошел!
Когда вы приступили к испытаниям, не смейте лезть в систему сразу! Постарайтесь пройти сначала всю формальную часть. Сверьте коды документации, носителей информации, откройте ТЗ, положите на стол Руководство пользователя. Пройдитесь по нефункциональным требованиям. ОС Windows — галочка. Поддерживаемые версии браузеров — раз, два, три, галочка. Язык разработки, архитектура, база данных, да мало ли что там в ТЗ понаписано! Все нужно показать в документации. Хотя бы там всего лишь одно предложение, оно обязано там быть! Не пренебрегайте этой бюрократией, тролли только этого и ждут. Вам хочется получить в протоколе, что «Исполнитель не продемонстрировал, что язык java является кроссплатформенным языком высокого уровня. Требования ТЗ 1.2.3 и 3.2.1 не выполнены»? А ведь это не придуманный маразм, это сама жизнь.
Когда вы закончили с формальной стороной дела, тоже не спешите лезть в систему! Следующая группа тестов заключается во включении монитора и демонстрации рабочего стола, иконок и запуска программы (если запуск нужно тестировать). Вход в систему с неправильным паролем, галочка, вход с правильным — опять галочка, галочка, галочка. Меню — эка невидаль! Главная форма, список чего-нибудь. Галочка.
Когда дойдет дело до нажатия кнопок в системе, комиссия уже порядком устанет и проголодается. А вы в первый день сможете проскочить, к примеру, основные справочники и базовые функции. А на другой день оставить бекапирование, администрирование и еще какую-нибудь ерунду.
Замечания
Они будут, можете не сомневаться. Нет такой системы, к которой не было бы замечаний. Ваша задача — заставить заказчика поделить все замечания на критические и не критические. Первые должны быть исправлены для успешного перевода в опытную эксплуатацию. Вторые могут быть исправлены в ходе опытной эксплуатации. Соответственно, лучше, чтобы первых вообще не было или были только те, исправить которые не представляет особого труда.
Когда заказчик делает замечание, вы фиксируете его формулировку в протоколе. Обязательно проговорите записанные слова, убедитесь, что вы друг друга поняли. Будет лучше, если в ходе испытаний будет работать диктофон. Постарайтесь сделать так, чтобы формулировка замечания была конструктивной, то есть, было понятно, что нужно сделать, чтобы замечание было снято. Слов «все», «ничего», «каждый», «любой», а также неизмеряемых качественных оценок «плохо», «медленно», «слишком быстро» и т.п. в замечании быть не должно! Если «система работает медленно», то должно быть написано «запрошенная форма должна отображаться в течении 5 сек». Если «символы на схеме плохо различимы», то должно быть написано «увеличить символы на схеме до 18 пунктов». И так далее.
Конкретизация позволит минимизировать возможность необоснованного перетаскивания того или иного замечания в ранг критического. Заказчик может утверждать, что отработка запроса за 6 секунд для него неприемлема, а за 5 секунд — в самый раз. Пусть это появится в протоколе! Но что-то мне подсказывает, что не появится. Или замечание будет признано некритическим.
Все замечания, признанные критическим фиксируются в акте: «Комиссия постановила, что система соответствует ТЗ и рекомендует принять ее в опытную эксплуатацию при условиях отработки следующих замечаний:...» При этом список некритических замечаний лучше непосредственно в акт не включать. Их обычно много и они могут напугать ответственного сотрудника, ставящего подпись. Если заказчик беспокоится, что вы не будете отрабатывать некритические замечания, успокойте его при помощи документа «Методика проведения опытной эксплуатации», котрый настоятельно рекомендуется подготовить. Там вы в простой и доступной форме должны описать как будет проходить опытная эксплуатация, как будут отрабатываться найденные баги и как будет заполняться журнал опытной эксплуатации, являющийся гарантом безболезненного окончания ОЭ, ввода системы в промышленную эксплуатацию и салюта с шампанским по причине окончания проекта.
Что делать, если все пропало
Когда вы понимаете, что испытания идут неудовлетворительно, система безобразно глючит, а заказчик уже исчерпал запас ругательств, не нужно сдаваться! Караван должен продолжать идти вперед, будет новый релиз, новые испытания. И даже если проект будет завален, ничего в этом страшного для вас нет. В условиях острого дефицита толковых исполнителей вы быстро найдете работу, тем более, что я бы на вашем месте не стал бы работать в компании, допускающей подобные ситуации.
Чтобы не терять время в бесплотных препирательствах, я бы рекомендовал применить тактику «бей своих, чтобы чужие боялись». Начните вместе с заказчиком ругать «этих криворуких программеров», «жадное руководство», а когда накал страстей уменьшится, предложите заказчику собрать максимум багов «этого глюкалова», чтобы показать этим нехорошим людям какие они нехорошие.
Тогда активные сотрудники заказчика во главе с троллем-киллером начнут собирать баги и радостно наполнять протокол сотнями замечаний. Фактически, за свои собственные деньги они проведут вам высокоуровневое функциональное тестирование, на которое, судя по результатам испытаний, ваши разработчики так и не сподобились.
По хорошему, описанной безобразной ситуации вообще быть не должно. Но проектный бизнес отличается иногда странными флуктуациями, когда первый прототип пытаются сдать как полноценную систему, начальство врет подчиненным и самим себе, все вокруг делают хорошую мину при плохой игре и уверяют друг друга в обязательном и непременном успехе.
Вторым советом в подобной ситуации было бы, как я уже говорил, сразу уволиться из конторы, допускающей подобные «косяки». Потому что по всем меркам настоящему профессионалу не стоит портить свою репутацию подобным образом.
Заключение
Итак, коллеги, на этом я спешу завершить трилогию о корпоративных троллях, которых не нужно бояться, а нужно уважать и даже некоторым образом любить, так как они не дают ленивым обезьянам ИТ бизнеса падать от обжорства с деревьев, держат нас в тонусе и даже привносят некоторый интерес в безумно скучные, но крайне необходимые проектные работы.
UPD от 23.06.2011. Пользователь igendo добавляет в комментариях, что неплохо бы уже на этапе заключения договора утвердить формы официальных документов проекта.
Цитирую:
Добавлю, что очень помогает в работе, когда формы актов, протоколов и прочих формальных документов зафиксированы в контракте. Дабы не было необходимости их предварительно согласовывать, пересогласовывать и переделывать\переподписывать в середине проекта.
От себя тоже могу добавить, что в совсем уж тяжелых и масштабных проектах принято составлять устав проекта, некий документ о глубинном смысле которого можно говорить часами. Там, кроме всего прочего, можно обговорить и формы документов проекта, и процедуры контроля хода проекта, и высокоуровневые бизнес-задачи. Но это, опять же, тема для другого поста.
Пользователь ЖЖ ryzhij_papa Добавляет, что существует практика ранжирования замечаний по степени их влияния на бизнес, методика ранжирования также заносится в ПМИ.
Цитирую:
Нужно формально описать что является замечаниями крического, высокого, среднего и низкого приоритета. Описание делается в терминах бизнеса. Если утрировать, то так: критический приоритет при потере 1000$, высокий если 100$, средний когда сотрудники в мыле, но убытков у нас нет, низкий — возможны случаи легкого умопомрачения на 5-6 году жизни с такой багой...
__________________
Да здравствует то благодаря чему мы несмотря ни на что!!!
|
24.04.2012, 21:36
) к исполнителям применяются методы троллинга.
