Однією з перших книг, яку я прочитала, коли вперше почала вести команду, була книга Тома ДеМарко «Peopleware: Productive Projects and Teams».
Ця книга - класика управлінської літератури. І хоча вона вперше побачила світ у 1987 році, викладені принципи залишаються вірними до цього дня. За свою кар’єру я прочитала багато книг, пов’язаних з менеджментом, але все одно вважаю, що ця книга справила на мене найбільше враження.
Я підготувала список ключових ідей з цієї книги, якими я тепер завжди користуюсь в роботі, і хочу поділитися ними з вами.
#1 Керуйте командою, а не кодом
Успіх проекту безпосередньо залежить від взаємодії людей, тоді як менеджери-новачки часто намагаються зосередитися на технічних аспектах. Зазвичай це відбувається тому, що керівнику, який виріс із розробника, легше вирішувати технічні питання. Таке ставлення може призвести до критичних проблем на проекті, про які ви не будете знати до останньої хвилини.
Люди — ваш найцінніший актив. Проект ніколи не буде по-справжньому успішним, якщо його створює група незнайомців, які просто збираються разом щодня з 9 до 5.
Команди створюють чудові проекти. Ваша робота, як менеджера — побудувати цю команду.
#2 Не гнобіть розробників за помилки
Для більшості девів та інженерів іншого роду час від часу робити помилки є цілком природною частиною їхньої роботи. Заохочення «середовища без помилок» просто зв’язує людям руки та не дозволяє їм пробувати нові підходи через страх невдачі.
Колись я сварила себе за кожну маленьку помилку. Це коштувало мені моєї самоповаги; це мало не коштувало мені всієї моєї кар'єри. Атмосфера в команді, в якій я тоді працювала, завжди ставала напруженою, коли справа доходила до помилок. Кожен маленький факап був об’єктом детального вивчення керівництва та глузування старших колег. Коли QA повертав нам тікет, тім-лід розпочинав ціле розслідування: як це сталося? Чому ви не зробили це правильно з самого початку? Що нам робити, щоб ніколи не повторювати цю помилку?
Я думаю, що його наміри були благими від природи. І це, по суті, правильні питання, які варто поставити розробнику, але ви повинні знати, коли і як їх ставити. Тому що в іншому випадку це призведе до повної непевності у власних силах у ваших співробітників.
Існує тонка грань між тим, щоб допомагати своїм товаришам по команді розвиватися, аналізуючи їхні слабкі сторони, і знущатися над ними, досліджуючи кожну їхню помилку під мікроскопом.
#3 Ставтеся до своїх тіммейтів як до людей
Це може стати для вас шоком, але ваші колеги — справжні люди, а не якісь роботи, що пишуть код. У них є свої злети і падіння, свої турботи і переживання. Ключовий спосіб завоювати лояльність людей — показати їм, що ви це розумієте. І що ви дбаєте про них.
Робіть дрібниці: дізнайтеся, що їх цікавить і що вони цінують найбільше; запитайте їхню думку; хваліть добре виконану роботу. Якщо у вашого колеги захворіла дружина — відпустіть його додому і запитайте згодом, як у неї справи; повірте, люди це високо оцінять.
Моя улюблена цитата з книги на цю тему:
Although your staff may be exposed to the message “work longer and harder” while they’re at the office, they’re getting a very different message at home. The message at home is, “Life is passing you by. Your laundry is piling up in the closet, your babies are uncuddled, your spouse is starting to look elsewhere. There is only one time around on this merry-go-round called life, only one shot at the brass ring. And if you use your life up on C++ . . .
І мій приблизний переклад:
Хоч вашим співробітникам і вселяють «працюйте довше та старанніше», поки вони в офісі, вдома їх навідують зовсім інші думки. А саме: «Життя проходить повз мене. Брудна білизна накопичується в шафі, сьогодні я ще навіть жодного разу не обійняв своїх дітей, а моя дружина починає задивлятись наліво. На цій каруселі, яка називається життям, у мене є лише одна поїздка, лише один шанс. І якщо я витрачу все своє життя на C++. . .
#4 Не нехтуйте якістю
Ми всі знаємо, що розробка - це завжди стрес, навіть в умовах аджайл, з усіма пропущеними дедлайнами та нереалістичними естімейтами. У всій цій катавасії якість кінцевого продукту (коду) - це далеко не одна з основних проблем менеджера.
Але мала б бути. Тому що правило «Quality? Only if we have time! » (якість коду? ну якщо встигнемо…) призведе до повної відсутності якості.
Накопичення технічного боргу, застарілий технологічний стек, спагетті-код — все це згодом змусить розробників покинути команду. Що призводить до відтоку знань з проекту і загальному низькому моральному духу.
Замовники часто не хочуть продовжувати час розробки, не даючи нам можливості обслуговувати технічний борг. В такому випадку, я зазвичай створюю детальний документ, який пояснює всі слабкі місця поточної кодової бази, до чого вони можуть призвести та як це вплине на розвиток продукту та бізнес клієнта в майбутньому.
Тут треба стояти на своєму: ваша команда відповідає за свою роботу, і ви хочете, щоб результат цієї роботи був гарним. Тоді і вони будуть від роботи отримувати задоволення.
#5 Створіть комфортне середовище
Коли ми всі ще працювали в офісі, однією з моїх головних проблем був величезний, шумний опенспейс з великою кількістю людей і критичною недостачею повітря для всього цього натовпу. Як розробник може бути продуктивним у такому місці?
У мене було стільки сварок із колегою через це, бо я завжди хотіла відкрити вікно, а він завжди хотів тримати його закритим. Такі типові офісні заворушки.
Ви, як менеджер, повинні створити середовище, яке буде комфортним для всіх. Де буде тихо, буде достатньо місця, де не буде жодних відволікань.
Навіть у домашньому офісі ця ідея все ще актуальна, особливо щодо відволікаючих факторів. Зведіть мітінги до мінімуму. Пам’ятайте: якщо людина не говорить на мітінгу, це надійний показник того, що її там не має бути. Просто надішліть йому потім email.
Дайте своїм розробникам трохи часу, щоб спокійно виконувати свою роботу.
Це деякі з основних принципів управління, яких було б добре дотримуватися, якщо хочете побудувати лояльну та продуктивну команду.
Узагальню все вищесказане своєю улюбленою цитатою:
The manager’s function is not to make people work, but to make it possible for people to work.
Задача менеджера - не заставити людей працювати, а зробити так, щоб люди могли працювати.
Дайте мені знати, якщо ця стаття була вам корисною, розкажіть, що ви думаєте, залишивши коментар, мені буде цікаво почитати. Дякую!
