Немного наблюдений про то, как хорошую работу отличить от плохой и чего не надо делать. Касается в основном IT, но и в обычной жизни отличий не сильно много.

1. Важный вопрос, который должен задать себе исполнитель: как достоверно проверить, что я сделал то, что просили, и оно работает так, как просили. При этом надо не скатиться в формализм вроде плохо написанных тестов, которые тестируют сами себя.

2. Иными словами, исполнитель должен уметь доказать заказчику (постановщику задачи) на доступном заказчику языке, что все работает как положено. Если заказчик плохо ориентируется в предметной области, с этим надо смириться.

3. Тот же вопрос должен задать и заказчик: как понять, что результат работы корректный, что исполнитель не сделал пустышку с красивым фасадом. Тогда не будет проблем вида “вы мне что-то делали год назад, я этим ни разу не пользовался, а теперь оно не работает”.

4. Хотя обычно важен результат, а не процесс, исполнителя, особенно нового, надо контролировать именно в процессе. Иначе есть шанс получить через пару недель “я делал, но у меня не получилось :(”

5. Когда я вижу такое “не получилось”, то задаю три вопроса:

• что именно не получилось?
• какие варианты решения проблемы ты пробовал?
• пробовал ли ты обратиться к кому-то за консультацией или за новой формулировкой задачи в более легком виде?

6. Очень редко удается услышать что-то вразумительное о причине неудачи. Навык “если ты собираешься облажаться, то облажайся красиво” полезный и редкий.

7. Часто приходится слышать “я работал над задачей неделю без видимого результата, потому что читал документацию”. Понятно, что такого быть не может: человек физически не может 5 дней по 8 часов что-то читать. Скорее всего, он потерялся, приуныл и прокрастинировал.

8. За этим обычно скрывается целый ворох проблем: плохая постановка задачи или ее несоответствие уровню исполнителя, отсутствие контроля и налаженной коммуникации, боязнь исполнителя задавать вопросы и признаваться в неудачах. С этим надо работать.

9. Никогда не надо давать задачи вида “изучить [название продукта|технология|ссылка на документацию]”. См п. 1 и 2. Все это должно происходить в практическом контексте, чтобы было понятно, для чего оно затевается и что надо получить.

10. И самое главное: не стыдно чего-то не знать или не уметь, признаваться в ошибках и учиться на них. Стыдно обманывать и скрывать неудачу.

11. Именно поэтому я очень люблю сети и официалов: корпоративный исполнитель обычно умеет понятно разговаривать, меньше забывает и теряет, не боится признаться в ошибке и придумать, как ее поправить, чтобы клиент ушел довольным.