Менеджмент, в первую очередь – работа с людьми. Управление и манипуляция (в хорошем смысле этого слова). Хороший менеджер сделает так, что его работа не будет обозрима, но все будут довольны и проект взлетит. Плохой менеджер наживет кучу врагов и сделает так, чтобы с компанией попрощались и клиент, и специалисты.
Что бы ты там внизу не прочитал, помни что люди это личности, а в психологии есть понятие калибровки – когда ты считываешь ситуацию/характер, и выстраиваешь поведение относительно считанного. В многообразии людей будет миллион различий, и один стиль управления со всеми сразу не сработает.
Работа с коллегами
Кто такой, этот коллега, который по каким-то причинам попал в твой проект? Он – человек, который помогает тебе добиться целей проекта. Ты – человек, который должен сделать так, чтобы у него получилось тебе помочь. Ты считаешь, что он, вместо того, чтобы делать задачу, занимается посторонними вещами. Он считает, что ты вместо того, чтобы работать, только тем и занимаешься, что дергаешь его по любому поводу, а сам особо ничего не умеешь. Угум, вы друг друга стоите. Только что это только твоя проблема.
Менеджмент очень много значит для процесса выполнения проекта. Редко встречаются именно ленивые люди – часто встречаются недостаточно мотивированные, недооцененные, люди не на своем месте. Плохой менеджмент способен испортить и проект, и заставить программиста искать новое место работы – помню с десяток таких случаев. Нужно отслеживать настроения, и решать потенциальные проблемы – даже на уровне отношений специалиста и компании, за пределом его работы в твоем проекте.
Коллега – не твой подчиненный, с ним не получится разговаривать свысока или наезжать – даже за косяки. И даже если такая возможность есть – этого делать не стоит. Получишь негатив, саботаж – все прелести конфликта, подрывающие рабочий процесс – оно тебе не надо. Если конфликт все-таки случился (а случился он точно не без твоей вины), лучше всего работает разговор тет-а-тет. Живая коммуникация в принципе способна решить многие проблемы. Разговаривая с исполнителями, ты получишь расположение, которое поможет тебе сейчас и в будущем.
Как ставить задачи
Ниже будет подробнее, в контексте работы с разными отделами – на примере креативной студии. Но есть и общие правила, которые можно соблюдать без учета департаментов.
- Задача должна быть понятна
- У задачи должен быть срок
Собственно, это все правила постановки задачи. А теперь подробнее:
Понятность задачи
Не веду речи о всяких SMART и иже с ними – хотя бы на шекелях разобраться пока. Представь, к тебе прилетает клиент, с запросом “нам нужно сделать такой лендинг, чтобы бизнес развивался”, и улетает обратно в свои бизнес-процессы. Лично я запросов с подобной понятностью получал сотни раз. Представь, что ты передал эту задачу дизайнеру, что получится? Если дизайнер – человек с опытом, то он тебя позовет обсудить эту задачу, задаст вопросы. И все это будет выглядеть так, что задачу продолбал конкретно ты. Если без опыта – он на задачу либо забьет, либо сделает не то, что понапридумал (но не сказал) клиент. Выясняем, что от нас ждут на выходе – только потом передаем задачу. Это сэкономит кучу времени и нервов.
Срочность задачи
Задачи бывают со сроком, и без срока. Те, что “со сроком” будут сделаны после наступления этого срока. Задачи без срока не будут сделаны никогда. При том, срок не должен быть “вчера”. При передаче проекта утверждаем срок со специалистом, и выводим его на видное место – функционал установки дедлайнов есть в любой системе управления задачами. Если срок продолбали – обсуждается и устанавливается новый срок. При этом, разбор полетов может понадобиться, если срок продолбан уж очень нагло. Нужно выяснить, в чем причина, и попробовать ее решить. Вероятно, у специалиста есть еще пять менеджеров, которые работают на принципе паники – у них всегда все горит. Специалист вынужден работать над его задачами, упуская твою. Или недостаточно технического бэкграунда – здесь можно сменить исполнителя или подключить дополнительные ресурсы.
Если срок был установлен, и программист (дизайнер, или кто-то еще) каким-то чудом успел до дедлайна и у него осталось время – не нужно срочно искать, чем еще его можно занять. Пусть самообразованием займется, ютуб глянет или в настольный футбол поиграет. Если есть понимание, что задачи не закончатся никогда, нет и мотивации их делать вовремя.
Сроки проекта в целом, никого кроме тебя и клиента не волнуют. То есть, нет смысла вывешивать дедлайн “мы должны сдать проект до 1 марта” – это невозможно измерить, к этому сроку невозможно прийти. Затем-то ты тут и нужен, чтобы раскидать задачи так, чтобы первого марта проект был сдан. Общая диаграмма Гантта никакого значения для проектной команды в целом не играет, никак не мотивирует.
А ниже уже мои субъективно-стереотипные взгляды на коммуникацию с ребятами, занимающимися разными штуками и задачами.
Руководство
Как ни крути, а у тебя есть непосредственный руководитель – тот, перед кем ты отчитываешься внутри компании. И таким образом, руководство также относится к проектной команде – не всегда, но часто.
Линий поведения у руководства три:
- Контролировать каждое движение в проекте
- Отдавать проект тебе на откуп, под полную ответственность
- Быть наблюдателем, “тайным советником”
Первый вариант, с неусыпным контролем – плохой вариант. Такое поведение размазывает ответственность – ты становишься уверен, что если что-то пойдет не так, то там вмешаются и разрулят. Плюс, это демотивирует и не развивает тебя как управленца. При работе с таким руководством нужно вспомнить о его интересах. Интересует его, в первую очередь, чтобы проект был рентабельным, а отношения с клиентом оставались хорошими. Скорее всего, будет достаточно, если руководство будет информировано о текущей ситуации в проекте. Можно даже придумать какую-нибудь систему внутренней отчетности. Конечно, при этом должна быть готовность нести ответственность за проект. Если информированности не хватит – поговори с директором, объясни, что такая линия поведения не очень хорошо влияет на работу. Если руководитель намека не поймет – можно искать альтернативное место, менять работу.
Когда на тебе полная ответственность – это уже лучше. Во-первых, стресса станет больше, а в стрессе быстрее учишься. Состояние, при котором ты чувствуешь ответственность за процесс и коммуникации добавляет осознанности работе. Перед тем, как работать в таком режиме – у тебя уже должно быть дофига опыта, здоровое хладнокровие и стрессоустойчивость. При работе с полностью доверяющим тебе руководством главное не умалчивать о проблемах, если такие будут иметь место быть. Потому что ты поиграешься в ответственность, не вывезешь и сможешь поменять работу, а ребятам после разгребать последствия твоего профессионализма. Это не путь самурая.
Вариант с “наблюдательством” – что-то между первым и вторым. По сути, лучший. Это когда у тебя полный контроль и ответственность, но тебя смогут поправить, если что-то пойдет не так. Каким бы навороченным проджектом ты ни был, со стороны косяки виднее. Главное, чтобы руководитель не ворвался в какой-то момент в стиле первого варианта. Это убьет и желание работать, и авторитет в глазах команды и клиента. Руководство, работающее в этом стиле – маст хэв в случае, если ты чувствуешь, что опыта явно недостаточно. Используй момент и ситуацию – преврати наблюдающего руководителя в ментора, в другое время бы еще денег доплачивал ему.
Отношение к руководству должно быть “горизонтальное”, без всяких понтов. В руках руководства рычаги, которые тебе не доступны, но могут быть полезными при ведении проекта. Руководству можно ставить задачи точно так же, как другим участникам проекта, и точно так же интересоваться сроками их выполнения. Все методы хороши, если они ведут к достижению цели.
Креативный отдел
Под этой фразой понимаем всех креативных ребят в целом – дизайнеры/копирайтеры/что там еще бывает. Исключая арт- и креативных директоров – эти ребята все-таки больше про управление и про помощь, примерно как руководство.
Творческий народ, находясь в проекте, не может быть творческим в полном понимании слова. В плане, нет у них права посылать проект лесом, потому что вдохновение не пришло. Принято считать, что дизайнеры предпочитают получать задачи в формате проблемы. То есть, без подсказки, что именно нужно сделать, а в виде проблемы, которую нужно решить. В реальной жизни все чуточку сложнее.
Опытным, искушенным дизайнерам лучше отдавать задачи на решение. С неопытными ребятами лучше всего работает второй подход – сказав, что именно нужно сделать. Скормив такому полноценную задачу, рискуешь не получить ничего. Лучше будет, если что нужно сделать скажет специалист из его же отдела – ведущий дизайнер или арт-директор.
При получении готовой задачи, нужно проверять ее выполнение, сравнивая задачу с изначальным техническим заданием. Если возникнут комментарии по внешнему виду – лучше их не давать, а поинтересоваться у дизайнера, почему было принято такое решение. Лучше будет если при согласовании каких-то необычных, спорных штук, на встрече поучаствует их автор. Дизайнера при согласовании можно заменить на арт-директора – если он действительно в курсе, почему было принято то или иное решение.
Технический отдел
К техническому отделу относим всех программистов, тимлидов, фронтенд, бэкэнд-разработчиков. Все те, объемы чьей работы не видны невооруженным глазом, но те, на чьих плечах все держится.
По моему собственному опыту, технические специалисты чаще обсуждают с менеджером решение, которое планируют применить к задаче. В проджект-менеджере они зачастую видят равного в технической подкованности человека, и сказать “я в этом не разбираюсь” такой себе вариант. Разбираться придется. Обсуждают подход и логику, почти не обсуждают реализацию – реализация не особенно творческий процесс. Адекватный программист никогда не придет с проблемой к менеджеру, скорее он придет с десятком решений. Неопытный программист равен неопытному дизайнеру – получив непонятную, сложную задачу, он будет ее делать до тех пор, пока ты не вмешаешься в процесс и не разрулишь ситуацию.
В техническом отделе находится по своей сути еще более творческий народ, нежели дизайнеры. Программисты очень не любят, когда им отдают расписанное техническое задание, или подключают человека, который займется продумыванием логики. В случае с джуниорами ситуация, конечно, проще – пока они учатся, готовы слушать старших товарищей. Если опытному программисту не давать возможности пробовать разные подходы самостоятельно, не повышать сложность работы – он уйдет из компании.
Контент-менеджеры, тестировщики, QA
В этом направлении низкий порог входа, и слишком широкое понимание и разброс предмета. Это дает сильный отпечаток на принципы работы. Например, тестировщик может быть “ручной” – работа которого заключается в проверить работоспособность частей проекта, может быть навороченный – там и автотесты, и скрипты, и все то, чем занимаются программисты.
Креатива в тестировании нет – здесь есть задачи, сроки и надежда на то, что на демо не вылезут неожиданные косяки. Ставим задачу => получаем результат.
Работа с клиентами
Если с коллегами ты видишься каждый день, и после завершения проекта люди продолжат встречаться в коридорах офиса, то с клиентом дело обстоит чуть иначе. Во-первых, нет такого понятия “клиент”, со своим характером, поведением и бест практицес по методам коммуникации. Есть компания или отдельный человек, который по каким-то причинам доверил решение задачи тебе/компании. От этого строится почти все взаимоотношения между проджектом на этой стороне и кем-то на той. С небольшими нюансами.
Клиент бывает:
- Стейкхолдер – лицо, принимающее решение и напрямую заинтересованное в решении проблемы
- Менеджер на стороне клиента – человек, которому поручили разрулить задачу, поддерживая коммуникацию с тобой
Относиться к задаче эти два лица будут по-разному: первый платит деньги, а второй их зарабатывает – на стороне компании-клиента. Тем не менее, весь проект так или иначе будет упираться в конечного заказчика. В идеале получить (или превратить) клиента в коллегу. Реальные психопаты встречаются не часто, все остальные выправляются переговорами. Да, клиентом ты тоже управляешь – немного изящнее и беспалевнее, но тем не менее.
Серебряная пуля в работе с любым заказчиком – его осведомленность. Нельзя скрываться надолго – даже если вы две недели пилили код, не вставая из-за компьютера, без статуса клиент будет считать, что вы ничего не делали. Негативный маркер – когда клиент запрашивает статус сам. В зависимости от требовательности клиента, периодичность статусов можно варьировать. Нечего рассказать? Как так нечего: если работаете – скажи, что задачи в процессе, и завершение ожидаем вот, через неделю. Не работаете – скажи, что не работаете, потому что фигня произошла – специалист заболел, сейчас решим проблему.
Случаются клиенты, которые дают кучу комментариев и пытаются контролировать процесс сверх меры. Важно понимать, что вы с клиентом по одну сторону баррикад, и в его поведении есть причины – попробуй донести это. К тому же, у клиента есть собственная экспертиза – в своей области он разбирается гораздо лучше тебя. Если же клиент лезет туда, в чем не разбирается – правильно будет указать, как лучше поступить в том или ином случае. Не в ключе “ты дурак и ничего не понимаешь”, а в виде совета. Если и в этом случае ничего не изменилось – делаем так, как того хочет клиент. Главное все это фиксировать. Все встречи и созвоны фиксируем через почту (это важно) – так к договоренностям можно будет вернуться, если кто-то о чем-то забудет в процессе.
С кем-то из клиентов возникают дружеские отношения – в профессиональных рамках. Это не повод расслабляться. Когда руководство представителя клиента воткнет ему за то, что ты по-братски продолбал проект – негатива будет даже больше. На “ты” общаться допустимо, если всем так окей.
Кроме клиента-лица компании, могут быть и разработчики со стороны клиента. И третьи компании, который консультируют компанию клиента, или тоже что-то делают. К ним всем следует относиться как к участникам рабочего процесса, без включения эмоционального элемента. Задачи-дедлайны-результаты. О работе с третьей компанией как-нибудь позже поговорим.
Контроль задач
Для контроля задач в компаниях обычно используется какая-нибудь внутрикорпоративная Jira/Redmine. Кроме этого, где-то ты сам должен вести свой микроменеджмент. Для этой цели я использую таск-трекер TickTick. А контроль задач происходит так:
- Поставил задачу в условном редмайне, добавил дедлайн
- Продублировал название задачи себе в Tick-Tick, отметил тот же дедлайн. В комментариях к задаче – ссылку на редмайн
- Если задача сложная, дедлайн жесткий, или есть риск, что специалист не справится – ставится промежуточная задача в Tick-Tick: название, дедлайн, ссылка
- Когда тебе прилетает напоминалка (или ты натыкаешься на задачу в листе Today) – маякуешь специалисту, с напоминалкой или запросом статуса. Соответственно типу задачи у тебя в задачнике
- Если задача переносится, переносишь ее и у себя
Все это нужно для того, чтобы не депрессовать человека лишний раз – только потому что ты вспомнил, что была такая-то задача и судорожно пытаешься выяснить статус. Это как стоять над плечом и спрашивать каждые пару минут “ну что там, как дела”. Избавиться от этого до конца не удалось и мне, но стремиться к избеганию такой спонтанности стоит. Как стоит доверять коллегам. С клиентами это работает точно так же – добавляй напоминалки себе. Ну и про свои задачи не забывай.
