Під час одного з тет-а-тет зі своїм керівником, я почула формулювання "це хороша звичка для менеджера". І я подумала, що в будь-якій професії, як і в житті, є хороші та погані звички.
У статті я поділюся тими звичками, які допомагають мені в моїй кар'єрі.
Звичка 1. Складай план на тиждень
В IT ми часто вживаємо формулювання "рухатися спринтами." Це означає, що будь-яку роботу можна розбити на етапи, і в кінці кожного з них ти очікуєш отримати певний результат. Для його отримання ти розподіляєш завдання між відповідальними. У цей момент можна легко забути, що в тебе самого теж є завдання.
Як правило, до інших ми більш вимогливі, ніж до себе. Щоб до своїх завдань ставитися так само серйозно, я їх обов'язково фіксую. Ставлю завдання в CRM на себе, відправляю відкладене повідомлення в Телеграм. І рухаюся тижневими спринтами.
Плюси звички:
- Короткострокові цілі або завдання хочеться зробити якомога швидше, щоб з'явився вільний час.
- Коли завдання записані, ти нічого не тримаєш у голові. Ніщо не упущено і не забуто!
- Викреслюючи завдання зі списку, ти почуваєшся впевненіше. Коли завдання в голові, ти не бачиш відсотків прогресу, а коли записані і викреслені, спрацьовує візуальне сприйняття.
- Тижневий спринт дає змогу не стресувати на вихідних, розмірковуючи про те, що зроблено, а що потрібно встигнути на наступний тиждень. Тобто, в п'ятницю ти зробив зріз за підсумком своїх завдань, підбив підсумки, а в понеділок плануєш новий
Приклад:
Уявімо ситуацію, що ви закінчили проєкт і клієнт пішов задоволеним. Комунікація припиняється, і ви з головою поринаєте в роботу над новими проєктами. Але ось тільки не забувайте, що набагато легше продати щось уже наявному клієнту. Тільки де знайти час, щоб підтримувати спілкування з тим клієнтом, з яким не ведеться активна робота? Я в план на тиждень собі пишу проєкти, які мені потрібно просто пропушити. Лист або повідомлення, на написання якого йде 1-2 хвилини, а в результаті - потенційний продаж для вас і робота з людиною, з якою вже є якась історія і ви один одного знаєте.
Звичка 2. Ставте багато запитань
Не знати щось - нормально. А ось не хотіти розібратися - вже інша історія. Як багато конфліктних ситуацій відбувається через те, що хтось когось не так зрозумів? Менеджер - клієнта, розробник - менеджера тощо. Це може бути порочним колом. Щоб так не сталося, я керуюся двома принципами:
- Не запитаєш ти - не запитає ніхто.
- Краще запитати кілька разів, ніж не запитати взагалі.
Запитання - дуже сильний інструмент, який можна використовувати в різних ситуаціях. Найчастіше добре поставлені запитання змушують думати людину в незвичній для неї манері. А ще вони дають приблизно половину вирішення поставленого завдання.
Приклад, коли моя любов до запитань допомогла мені і всьому проєкту:
Перед запуском сайту, фінальним завданням було оптимізувати швидкість завантаження сайту. Одним із популярних інструментів є Pagespeed Insights від Google. Зазвичай він дає базові рекомендації та оцінку швидкості сайту як на десктопі, так і мобайлі. Тільки ось нюанс у тому, що впроваджені рекомендації не обов'язково спрацюють для вас, а також зі зміною алгоритму оцінка теж змінюється.
Для розв'язання питання щодо оптимізації швидкості сайту нам допоміг діалог із розробником, у якому з мого боку були практично одні запитання:
Я: Як ми можемо ще оптимізувати швидкість завантаження? Які показники тягнуть швидкість вниз? Розкажи докладно, що це за показник "отримання першого байта від сервера" і чи правильно я його розумію?
Розробник: Отримуючи URL, браузер відправляє запит на сервер, сервер віддає інформацію, яку браузер відтворює.
Я: Ок, чому нам довго відповідає сервер? Може потрібно потужніший?
Розробник: Ні, сервер не завантажений і потужності вистачає. Можливо, потрібно дивитися запит, у нас там багато перевірок URL-а.
Я: Які перевірки?
Розробник: Що показати користувачеві, залежно від міста, мови, всі блоки відрізняються. Плюс, ми маємо визначати найближче місто, це пов'язано ще зі швидкістю відповіді стороннього сервісу.
Я: А навіщо нам ця перевірка? Ми ж відмовилися від цього.
Зрештою, ми прийшли до того, що ця перевірка вже давно втратила свою актуальність, тому ми оптимізували запит, і це дало приріст за швидкістю.
Вище лише один приклад розмови щодо одного із завдань, але таких безліч, як з командою, так і з клієнтами. Своїми запитаннями, ти можеш спрямувати людей, змусити їх мислити більш творчо, шукати відповіді на нестандартні питання, які вони самі собі не ставили і не підозрювали про їхнє існування.
Звичка 3. Надсилай followup
На зідзвоні обговорили нові вимоги? Або була зустріч, після якої є відчуття конфлікту, що назріває? Зафіксуй усе, що ви обговорили, і надішли на учасників листа з резюме бесіди - followup.
У ньому має бути така інформація:
- Що обговорили і про що домовилися (наприклад, додати нову сторінку на сайт)
- На що це впливає, і які ризики є (наприклад, впливає на вартість і терміни робіт)
- Які дії потрібні від кожної сторони (наприклад, Замовник - написати вимоги до сторінки, надіслати приклади; Виконавець - оцінити завдання)
Приклади ситуацій, у яких мені допомогла ця звичка, наведу у вигляді діалогу:
Клієнт: А я думав, що ви оцінили одразу все завдання, а не тільки дизайн.
Я: У своєму листі (скріншот) я писала, що входить у 6 годин роботи, і що точну оцінку зможемо зробити після дизайну.
Клієнт: А чому ви ще нічого не зробили? Ми ж на зідзвоні все вам розповіли.
Я: Так, усе правильно, Ви розповіли, що потрібно буде оцінити доопрацювання за вашим проєктом після робіт іншої команди. Щоб оцінити, нам потрібні доступи до проєкту для того, щоб переглянути код. Писала в листі, які доступи нам потрібні (скріншот).
Висновок: хороший followup врятує тебе не раз. Якщо твій аргумент "ну ми ж обговорювали місяць тому телефоном" - це не аргумент. Коли немає зафіксованого доказу - вважай, що його немає взагалі.
Followup обов'язково писати в тих випадках, коли ти відчуваєш, що є хоча б маленька ймовірність, що це забудеться або вилізе тобі потім боком. Ясна річ, якщо тобі зателефонували на секунду і попросили замінити одне слово, то навряд чи для цього варто писати followup. Хоча...
Звичка 4. Надіслати тижневий звіт
Людині властиво нервувати в стані невизначеності. Ваші клієнти - експерти у своїй ніші. А ви експерти у своїй. Тому вам потрібно навчати клієнта, щоб він краще розумів, що відбувається на вашому боці. І звіти в цьому дуже допомагають. Тому що основна частина конфліктів відбувається саме тому, що клієнт:
- Не розуміє, що ви робите зараз.
- Що будете робити далі.
- Як це (реалізація послуги) взагалі відбувається.
Написавши тижневий звіт, ви даєте людині знання ситуації і відповідно відчуття її контролю. У тижневий звіт варто писати:
- Що зроблено цього тижня
- Що планується зробити наступного тижня
- Питання, які є.
Приклад:
З клієнткою обговорили список робіт, які робитимемо на сайті поступово протягом наступного року, коли буде час після виконання важливіших завдань. Тобто домовленість робити роботи є.
Після цієї домовленості минуло кілька місяців, термінових завдань немає і ми можемо починати якесь завдання з того списку.
Я пишу в тижневому звіті, що ми плануємо виконувати її наступного тижня і прошу підтвердження. Після чого, лунає дзвінок, і виявляється, що це завдання вже не таке актуальне і краще його не робити.
Звіт, у якому я написала план, допоміг оновити пріоритети завдань, які змінилися, і вас про це не попередили. Звіт допоміг уникнути витрати часу, невдоволення клієнтів, руйнування нервової системи розробника.
Звичка 5. Дякувати команді
Ця звичка досить проста. Говори "дякую". Навіть якщо співробітник зробив "свою ж роботу". Тому що кожна людина виконує і розуміє "свою роботу" по-різному.
У мене є дідусь, для якого все просто - є начальник і є підлеглий, і іноді він мене запитує "У тебе є команда, то ти начальник?".
Можливо, для мене слово "начальник" має якесь негативне забарвлення, але я його не вживаю в принципі. Ви команда, у вас одна мета, завдання. Менеджер у цій ситуації лідер. Кожному менеджеру варто пам'ятати, що якщо ставитися до члена команди, як просто до "виконавця" завдання, то навряд чи це буде гра в довгу, і навряд чи цей працівник допоможе тобі, коли якесь завдання буде горіти, а вже 18:00 і робочий день закінчено.
Тільки за людського ставлення в колективі, взаємної подяки один одному, ви будете вершити великі проєкти.
Звичка 6. Не йди сліпо за процесом і вмій адаптуватися
У кожній компанії прописані процеси, у кожній методології управління проєктами є процеси. У більшості випадків вони полегшують життя, але завжди є ситуації, коли для якогось завдання і для якогось клієнта потрібно відійти від процесу.
Зазвичай, ми не любимо відходити від процесів, до яких звикли, але хочемо, щоб їх порушували заради нас, ось такий парадокс :-)
Без навички адаптації людина навряд чи б вижила в принципі. Менеджер має вміти адаптуватися.
Кілька прикладів:
- У вас за процесом відправляти тижневий звіт, а клієнт просить дзвонити йому
- За процесом не можна вносити зміни в п'ятницю, але Замовник просить лише змінити колір кнопки і нічого страшного не повинно статися
Намагайтеся не упиратися і намагатися підлаштувати під себе, а йдіть назустріч і шукайте компроміси. Найчастіше клієнти, члени команди, колеги запам'ятовують такі "плюшки". Звичайно, завжди оцінюйте ризики і мисліть розсудливо. Якщо клієнт просить вас не укладати договір і оплатити роботи після виконання, це теж відхилення від процесу скоріше за все, але ви навряд чи на нього підете з розумних причин.
Звичка 7. Говори свою думку
Є різні типи клієнтів. Комусь потрібен просто виконавець завдань, і думка цього виконавця самому клієнту не цікава. Є навпаки ті, які очікують прояв ініціативи від команди. У будь-якому разі менеджер має озвучувати свою думку і думку своєї команди.
Якщо Клієнт просить зробити якусь функцію на сайті, яка, на його думку, зможе заробити мільйони, а ви думаєте інакше, і команда взагалі не хоче це робити, тому що "цим не користуватимуться", ви маєте це озвучити клієнту. Навіть якщо він вас не послухає, а наполягатиме на своєму, він почує про ризики і про те, що думаєте ви. А якщо ви не скажете, зробите, то, найімовірніше, потім будуть запитання до вас: "Ви ж експерти, ви що не могли порадити, як краще!" Пам'ятайте, що це не проєкт клієнта, це ваш спільний проєкт.
Звичка 8. Не підгорай
Менеджер - це постійна комунікація і робота з людьми, тож нервами на всі ситуації не запастися. Якщо ти не будеш сьогодні спати, бо думаєш, а як мені завтра написати листа, погано тільки тобі в цій ситуації. Навряд чи клієнт лежить у цей час і думає "а який лист мені завтра напише менеджер?".
Зрозуміло, що ми не роботи, і повністю відключити свої почуття навряд чи вийде. Але оскільки завжди будуть ситуації, які виводять нас із себе, є кілька принципів "не підгорати":
- Пам'ятай, що це лише робота, і оцінюй адекватно наслідки якихось ситуацій. Навряд чи 5 хвилин непрацюючого сайту принесуть збитки в ті суми, які називаються. Навряд чи кнопка, яка змістилася на 2 пікселі, змусила людину зателефонувати в компанію і розповісти, який у них поганий сайт.
- Знайди те, що тебе відволікає від стресу. Потрібно вийти випити кави? Вийди. Хочеться піти побити грушу? Запишись на тренування.
- Намагайся поменше нервувати перед командою. Усі пам'ятають промови полководців у фільмі перед битвою? Ніхто там не говорить "блін, можливо, у нас будуть втрати мільйони, і взагалі в них армія в 10 разів більша" і т.д. Ви драйвер для своєї команди. Ви маєте мотивувати їх до дії, а не заражати панікою. Знову ж таки, якщо періодично команда бачить, що ви переживаєте, це теж ок. Але якщо ви постійно в стресі, то, найімовірніше, ви викликатимете в них менше довіри.
У четвер о 19:00 демка за проєктом. Понеділок/середа ми виправляємо баги, але знаходяться все нові й нові. У четвер вранці після дейлі з командою ми зрозуміли, що жоден функціонал не працює остаточно. Варіант перенести демку не бажаний, тому що заздалегідь про це попередити не вийде, у клієнта зараз ніч. У підсумку намагаємося зробити все, що встигнемо. У кімнаті розробників на той момент перебувало близько дванадцяти осіб, троє з яких працювали на моєму проекті.
Зайшовши в кабінет о 14:00, я побачила, що панує паніка. Вони бігають один до одного, запитують щось, чекають, коли ж усе задеплоїться.
Я вийшла в середину кімнати і зробила оголошення приблизно такого змісту: "Хлопці й дівчата, видихніть усі, будь ласка. Так, у нас демка, я знайду спосіб що і як показати клієнту, тому що у нас є інструменти, які працюють. Усе буде гаразд, зараз заспокойтеся і просто закрийте баги, які зможете".
Простий монолог вплинув так, що за 5 годин до демо було зроблено більше, ніж за 3 дні.
Незважаючи на те, що в статті я зібрала вісім корисних звичок менеджера, список можна продовжувати і продовжувати. Головне - постійно розвиватися, прокачувати свої хороші звички і викорінювати погані. Ідеального менеджера для всіх не існує, але для якогось проєкту ви обов'язково ним станете.
