Уходящий сотрудник пишет его сам или предоставляет это право начальнику – на его усмотрение (в Basecamp большинство писали сами). В любом случае такое письмо должно появиться на свет. Потом уходящему сотруднику показывают ответы коллег. Обычно те присылают фотографии и делятся воспоминаниями. Прощаться всегда нелегко, но необязательно делать это с прохладцей или чересчур официально. Всем известно, что обстоятельства меняются и жизнь может преподнести любые сюрпризы.
Отметим, что, если в первом послании не упоминаются причины ухода, начальник в течение недели рассылает всем второе письмо с объяснением. Если человек переходит на другую работу, обычно он об этом рассказывает. Но если он был уволен, нам приходится самим писать об этом. Важно, чтобы все были в курсе причин и в воздухе не повисали вопросы без ответов.
Вот это и есть спокойное «прощай».
ЧАРЛЬЗ ДИККЕНС ПРИДЕРЖИВАЛСЯ СТРОГОГО РАСПИСАНИЯ: ПЯТЬ ЧАСОВ РАБОТЫ В ТИШИНЕ, А ЗАТЕМ ТРЕХЧАСОВАЯ ПРОГУЛКА.
Анатомируйте процесс
Неподходящий момент для общения
Постоянно участвовать в групповом чате все равно что весь день сидеть на совещании безо всякой конкретной темы. Такое времяпрепровождение безумно утомляет.
Общение в чате – это непрерывно движущийся конвейер. Если вас не оказалось на месте в начале разговора, вы уже не успеете вставить свои пять копеек. То есть если вам есть что сказать, надо следить за беседой весь день (а иногда и за несколькими «комнатами» или каналами). Конечно, от чатов можно отключиться, но тогда придется преодолевать страх упущенных возможностей. Сомнительный компромисс…
Чатами нужно пользоваться разумно. Они удобны, когда надо быстро выяснить что-то срочное или ввести коллег в курс дела. (Еще он хорош как замена «курилке» – где люди болтают о всяких пустяках, сплачиваясь в паузах между работой.)
Но находясь в «комнате» срочных сообщений, важно не перейти тонкую грань и не начать считать своим долгом подвергать немедленному обсуждению каждую реплику. Почти все должно и может подождать, пока спрашивающий не проявит настойчивость.
При этом есть риск, что молчание сочтут знаком согласия. «Как ты не согласен? Мы же обсуждали это в чате». – «Я ничего об этом не знаю, меня не было, я работал». – «Ну, очень жаль, но мы все обсудили и решили, что ты не против, раз молчишь». – «Черт!» Если решения принимаются в чатах, таких недоразумений не избежать.
В отношении чатов мы завели два правила: «Иногда в реальном времени, но в основном асинхронно» и «Если это важно – не торопись».
Серьезные темы требуют времени. Необходимо, чтобы они были сформулированы отдельно от остальной болтовни и к их обсуждению подключились все сотрудники. Дабы не дробить важную информацию, мы просим написать краткий обзор. Это соответствует правилу «Если все должны это увидеть, не замусоривай чат». Таким образом, дискуссия не уползет из окна через пять минут.
Многие руководители полюбили групповые чаты за возможность в любой момент заглянуть в них и донести информацию сразу до всех. Сотрудники же из кожи вон лезут, чтобы создать видимость присутствия в чате и при этом успевать выполнять свои прямые обязанности.
В сфере разработки ПО принято во всем винить пользователей. Эти неумехи вечно делают все неправильно – а надо вот так и вот эдак. Но на самом деле их поведение зависит от дизайна. И если он вызывает стресс, значит, он плох.
Чат полезен в малых дозах, не объедайтесь им.
Дредлайны
Большинство дедлайнов мы бы назвали скорее дредлайнами, то есть нереальными сроками с постоянно растущими требованиями к проекту. Работа накапливается, а времени больше не дают. Это не работа – это ад.
Без фиксированных, разумных пределов невозможно спокойно работать. Осознавая, что не сможешь выполнить все необходимое в заданный период, или получая дополнительные задания, начинаешь действовать в лихорадочном состоянии. Авралы не приводят ни к чему хорошему.
Мы всё делаем по-другому.
Дедлайны в Basecamp строгие, но фиксированные и разумные. Если надо сдать 20 ноября, значит, надо сдать 20 ноября. Дата не сдвинется ни вперед, ни назад.
Меняться может только объем работы – но лишь в меньшую сторону. Нельзя устанавливать дедлайн, а потом увеличивать объем. Это неразумно. Проекты у нас только уменьшаются, а не разрастаются. Постепенно мы отделяем обязательные задачи от дополнительных плюсов и отбрасываем лишнее.
А кто решает, что делать и чего не делать в заданный период? Команда. Не генеральный директор и не технический. Процессом управляет выполняющий работу коллектив. Он рулит «штурвалом диапазона» (принятый нами термин). Он делит большие обязательные вещи на составные части и рассматривает каждую индивидуально и объективно. Затем сортирует их, фильтрует и решает, за что взяться сразу, а что может подождать.
Важно, чтобы диапазон поддавался уменьшению, потому что почти все, что займет шесть месяцев, можно в той или иной форме закончить за шесть недель. Маленькие проекты раздуваются с тем же успехом, если за этим не следить. Надо знать, когда закончить, когда остановиться и когда продолжать.
Наши дедлайны основаны на бюджете, а не на приблизительной оценке. Давайте смотреть правде в глаза: люди в большинстве своем не умеют адекватно оценивать задания. Зато прекрасно умеют устанавливать и расходовать бюджет. Если сообщить команде Basecamp, что у нее есть шесть недель на создание первоклассной функции календаря, сотрудники с большей вероятностью сделают отличную работу, чем если спросить их, сколько времени им нужно на разработку данной конкретной функции календаря: ради нее они останутся без выходных и будут надрываться.
В дедлайне с гибким объемом работ допустимы переносы и компромиссы – составляющие здоровой, спокойной работы. Одновременное же изменение диапазона и времени обычно приводит к сверхурочной работе и нервному истощению.
Вот основные признаки дредлайна.
Неподъемное количество задач, которые надо выполнить в неразумно короткий срок. «Основной редизайн и реорганизацию планируется осуществить за ближайшие две недели. Я знаю, что половина команды в это время будет в отпуске, делайте что хотите».
Завышенные ожидания с учетом недостатка ресурсов и времени. «Нельзя поступаться качеством, к пятнице все должно быть идеально. Сделайте все возможное».
Увеличение объема работы на изначально заданный период. «Мне директор только что сказал, что к английской версии надо добавить испанскую и итальянскую».
Ограничения дают свободу – именно таковы разумные сроки с гибким диапазоном. Но для этого придется опираться на бюджет и забыть о приблизительных оценках. В обозначенное время работа пройдет отлично, если этому не мешать.
Не реагируйте бездумно
Для обсуждения новой идеи сотрудники, как правило, резервируют переговорную комнату и созывают совещание. Если повезет, презентация проходит без форс-мажоров. (Но обычно уже через пару минут прибегает ответственное лицо с очередным поручением и вносит смуту.) Затем слушатели реагируют на услышанное и увиденное. В этом и заключается проблема.
Предполагается, что докладчик вложил много времени и сил в подготовку и донесение до аудитории своей идеи. И вот на нее просят отреагировать. Не усвоить, не обдумать, не рассмотреть – просто отреагировать. Так не годится. С хрупкими новыми замыслами следует обращаться более бережно.
В Basecamp все по-другому.
Мы почти всегда излагаем идею письменно. И представляем ее в законченном виде как многостраничный документ. По возможности с иллюстрациями. А затем сообщаем всем, кого это касается, что новая идея ждет, когда с ней ознакомятся.
Внимание!
Нам не нужна реакция. Нас не интересует первое впечатление. Нам ни к чему импульсивные высказывания. Мы ожидаем обдуманной обратной связи. Прочитайте всё. Дважды или трижды. Не спеша осмыслите и сформулируйте ответ – так же как автор идеи облекал свое детище в удобоваримую форму.
Это глубокий подход к делу.
За презентацией идеи в Basecamp обычно следуют несколько дней молчания, а затем идет волна ответов. Это нам и нужно. Представьте себе тишину после презентации – получилось бы неловко. Вот поэтому мы и предпочитаем заочные, а не очные обсуждения. Тщательное обдумывание требует тишины, а не суеты.
Таким образом, мы эффективно «держим зал». Онлайн-презентации нельзя помешать внезапным вторжением. Идея излагается полностью – никто не перебивает. Ответная точка зрения – тоже.
Попробуйте наш подход сами. Не организовывайте встречу, а пишите. Не реагируйте, а думайте.
Берегитесь двенадцатидневной недели
Давным-давно мы выпускали новые программы по пятницам. Соответственно, в субботу и воскресенье иногда приходилось решать срочные проблемы, и выходные пропадали. Это было глупо, но предсказуемо, потому что мы ставили себе срок на конец недели. Пятница – худший день для этого.
Во-первых, люди всегда будут спешить. То есть сданная в пятницу работа, скорее всего, будет с недочетами.
Во-вторых, за пятницей следует не понедельник, а суббота с воскресеньем. И если что-то пошло не так, выходных не видать.
В-третьих, работая в выходные, не успеваешь набраться сил. После целой недели понедельник получается восьмым рабочим днем, а не первым. А следующая пятница – двенадцатым. Это не дело.
Нас угораздило устроить себе такой стресс. И он не заканчивался с выпуском, а продолжался. Кстати, мы так и не поняли, почему, но теперь вместо пятницы выпускаем обновления по понедельникам. Тут появляются другие риски: ошибки выявляются в самый суматошный день недели. Но, помня об этом, мы лучше готовимся к выпуску.
В частности, чтобы заблаговременно «поймать» все ошибки, мы усилили контроль качества. Для снижения стресса в день Х мы применяем комплексный подход. Главное – осознать проблему, а решение обязательно найдется.