Соответственно, ключевые результаты деятельности для технического писателя оказались таковы:
* есть понятные и полные правила и инструкции по разработке (для программистов) и эксплуатации (для заказчика) программного обеспечения, понятные и полные правила игры (для пользователя);
* программистам все понятно в инструкциях, вопросов нет или их очень мало;
* заказчику понятно, как эксплуатировать программное обеспечение, по вопросам эксплуатации программного обеспечения заказчик быстро находит ответы (сам или с помощью подсказки сотрудника компании).Заметьте, что здесь мы намеревались не просто отписаться общими фразами, а хотели докопаться именно до ключевого различия между «есть какой-то результат» и «есть правильный результат». Ведь просто разработать абы какую инструкцию – это одно, тут, как говорится, много ума не надо. А вот разработать такое руководство, чтобы у того, кто им пользуется, не возникало вопросов и претензий к автору, – это уже другое, и далеко не каждый способен справиться с этой задачей.
Итак, когда стало ясно, что должно быть «на выходе», пришло время определить, какой человек подойдет на эту вакансию. Классический вариант – это искать сотрудника с опытом работы и участия в подобных проектах. Однако, как вы уже догадались, мы изначально отказались от такой стратегии. Почему? Во-первых, наличие опыта работы почти автоматически завышает для компании «стоимость» нужного специалиста. А во-вторых, мы свято верили в то, что наличие способностей к работе и «правильных» привычек у соискателя во много раз важнее, чем присутствие опыта работы!
Поэтому после определения результатов работы технического писателя, а также зная о том, что чем меньше у нас «входных» требований к кандидату, тем проще найти нужного человека и тем дешевле он обойдется фирме, пришла очередь составления максимально короткого списка требований к соискателю. То есть таких требований, без которых «совсем никак» и которые оказывают самое непосредственное влияние на получение обозначенных нами результатов.
Вот что у нас получилось.