1. Постановка задачи коротко на словах.
К разному это приводило. Иногда задачу делали быстро и хорошо. Иногда что-то забывали. А иногда ее просто не делали, а потом еще и говорили, что задачи не было.
Вывод. Достаточно быстрый и удачный метод для небольших и простых задач, а так же когда вас слушают и понимают. Подразумевается, что такая задача должна быть выполнена, как можно быстрее.
2. Короткое описание задачи, но уже на e-mail.
К сожалению ICQ, Skype – это не так надежно. В почте меньше вероятность отмахаться по типу “ой, а я не получил”, “ой, а оно мне дома пришло и я забыл” и т.д.
Если вас слушают и хотят понять, то это отличный способ. Вы не тратите много времени, а результат получают. В других случаях основная проблема это, то что задача короткая. Велик шанс быть неправильно понятым. Это и есть самая классическая отговорка, с которой я сталкивался: “тут ни ясно написано”. Очень удачно использовать, когда задача маленькая и не требует больших затрат времени, но сотрудника нет на работе (в поле досягаемости). Подразумевается, что такая задача должна быть выполнена, как можно быстрее.
3. Полное описание задачи в каком-то софте (таск-трекер / какой-то софт по совместной работе и т.д.).
Это самое нормальное, когда ты не знаешь, с кем ты работаешь или большая и сложная задача. Если ты работаешь с проверенными людьми, которые не первый раз видят этот проект, или проекты шаблонные, то можно не расписывать каждую новую задачу по полной. Если мозг detected, то они сами знают и сделают как обычно. Если же задача новая, то надо описывать всё и полностью. Опять же, если человек “свой”, то важно донести цель и задачу того, что он пишет. Всегда помните о том, что вы не самый умный, а специалист всегда может что-то подсказать. Но для этого специалист должен понимать зачем оно это все надо. Если же это просто исполнитель (в плохом смысле), то не утруждайтесь донесением целей. Все равно будет сделано ровно то, что написано.
Подобные задачи не могут быть выполнены “как можно быстрее”. Такие задачи всегда должны иметь срок. Задача без срока – не задача.
4. Readme – сделай файл и спи спокойно.
Очень интересный аспект. Если вы ставите задачу профи, то профи (глядя на дизайн/верстку и т.д.) на 80% уже знает, что делать. Особенно учитывая, что я описываю опыт работы в веб-студии, а это конвейер, то и на все 99% каждый знает, что делать. Так вот в редких случаях достаточно сделать файл readme и отравить вместе с psd/html/etc. Но так можно только с проверенными людьми.
Все любят работать с людьми, которые добросовестно выполняют свою работу. Я не исключение. Висеть над душой у человека круглосуточно это не очень веселое занятие. К тому же если видно, что человеку плевать на то, что он делает, то как можно ставить такому человеку задачу? С такими людьми лучше не работать.
Сейчас работаю с верстальщицей (всем рекомендую! за контактами обращайтесь лично) – все супер. У всех есть свои недостатки. Но для этого собственно и есть менеджеры, которые знают их и умеют с этим работать. Начинали мы с тех. заданий на верстку, потом ТЗ уменьшались в объеме, потом некий свод правил, а сейчас просто readme файлы периодически и все.
Выводы (аккуратно, чистое ИМХО!):
- если человек не хочет работать, не надо с ним работать;
- незаменимых людей нет и вы полный @&#$#$%$#%, если сотворили в своей команде незаменимого человека;
- донести зачем это надо важнее, чем донести детали чего непосредственно надо;
- не работайте с теми людьми, которые к вам относятся плохо (пусть даже они выполняют свою работу) или к которым вы относитесь плохо. Команда включает понятие “единомышленники”.
Я хочу написать о том, как сотрудники живут в одном мире, а руководитель в другом.
В предыдущем