Колеги в Design and Test Lab Володимир Обрізан, кандидат технічних наук, директор компанії та Оксана Павловська, Senior Project Manager нещодавно дискутували на Youtube на тему саботажу на роботі — що це таке, що є ознаками саботажу та як з ним боротися.

Виявлення саботажу на роботі є важливою задачею для забезпечення безпеки та нормального функціонування організації. У статті ми хочемо описати текстом матеріал про саботаж на роботі та більш розібратися в цій темі. Поїхали!

Що таке саботаж на роботі

Саботаж на роботі відноситься до дій або поведінки співробітника або співробітників, які спрямовані на завдання шкоди або заважання нормальному функціонуванню організації чи робочого процесу.

Приклад саботажу на роботі в IT:

Після тестування чергової версії додатку знайшли нові помилки через те, що розробили новий функціонал та зламали старий. Але замість того, щоб піти та виправити ці помилки, почалася сварка між розробниками та менеджерами: розробники кажуть, що треба йти за записати усі вади до тікетів, потім вони сказали, що такої поведінки не було записано в документації, хтось пригадав “а ось мені казали в чаті робити цю функцію по іншому”. А потім взагалі почалося як в “Хрещеному батьку” — “ти попросив мене виправити цю помилку не надто ввічливо”… І тоді у менеджеру проекту зародилося відчуття, що розробники саботують роботу.

Ця стаття написана на основі Simple Sabotage Field Manual by United States. Office of Strategic Services — документ, який розроблений у США під час Другої світової війни. Основний зміст — надати можливість звичайним громадянам, які працюють в тилу у загарбника робити прості речі, але ці речі підривають обороноздатність та спотворюють промислові процеси. https://www.gutenberg.org/ebooks/26184.

Давайте розглянемо інструкції на прикладі розділу з даної методички про адміністративну роботу та роботу в офісі покроково і подивимося, які з них зараз можуть траплятися на IT проектах, бути маркерами “саботажу” та що з цим робити.

Відійдіть від екранів! Як розпізнати саботаж на роботі. Порада №1.

Наполягайте на тому, щоб зробити все по порядку через усі офіційні “канали”. Ніколи не дозволяйте використовувати короткі шляхи, щоб прискорити прийняття рішень.

Так справді буває в звичайних процесах — коли люди не хочуть якнайшвидше вирішити питання і починають вимагати завести всі тікети в Jira, піти до всіх ключових людей і попросити їх дописати вимоги, поправити тікети, верифікувати у БА та ПМ, запропонувати поставити задачу і дати на виправлення, хоча це виправлення займає 5 хвилин.

Чому це шкідливо? З одного боку, ми робимо все за правилами, є бізнес-процесс. З іншого боку, якщо є питання, які можна вирішити коротким дзвінком або у чаті, то краще зробити саме так! У подкасті Чи потрібні менеджери? Що таке self-managed teams? як раз розповідається про те, що можна не ускладнювати процес вирішення, а вирішити це особисто між співробітниками.

Цей саботаж може бути усвідомлений, а може й ні. Але керівнику всеодно, тому що краще, щоб такого не було на проекті.

Вимагайте, щоб усі таски були записані в Jira. Порада №2.

Команда розбирає задачу і хтось каже: “Ця задача для мене надто завелика. Треба, щоб її розбили на підзадачі та записали кожний тікет”. Це мікроменеджмент — якщо функціонал можна зробити комплексно, зрозуміло, за бізнес-процесом та одразу, то не треба додавати роботу інших членів команди для цієї активності.

Іноді це завдання виконується з швидкістю, що тікет в Jira довше записати, чим піти та зробити.

- Приклад для програмістів: Коли ми робимо демо або на щось зламалося на production, то немає часу на інші активності, окрім вирішення даної ситуації.

- Приклад для Project Managers: завести тікет на написання для кожного мітингу Agenda, Meeting Minutes.

Посилайтесь на те, що ви не можете особисто прийняти рішення, та треба зробити нараду. Порада №3.

Посилайтесь на те, що ви не можете особисто прийняти рішення, та треба зробити нараду, щоб ще це вивчити та зробити рішення. Наполягайте, щоб на нараді було як мінімум 5 співробітників.

“Щоб це вирішити, давайте запросимо всіх!” — у цьому випадку вартість виправлення стає неймовірною! У подкасті Ефективні міти — чи бувають взагалі? можна зрозуміти, що іноді мітинги — це антіпаттерн 😁

Таким чином ламається делегування: надати співробітнику повноваження вирішити завдання, а співробітник уникає цього та хоче зібрати нараду для “допомоги”. Тобто делегування не працює! Тому це й є саботаж на роботі.

Роби що завгодно, щоб не виконувати завдання. Порада №4.

Роби що завгодно, щоб не виконувати завдання. Навіть якщо 90% можна зробити не маючи повне завдання — не роби нічого, доки тобі не нададуть усю повну інформацію.

Наприклад, команда хоче ідеальні дизайни замість того, щоб використовувати типові елементи стайл гайду та не починає роботу без цього. А це 1% роботи! Можна зробити структуру бази даних, зробити контроллери на бекенді, АПІ-коли, зробити будь-який HTML, тобто виконати 99% роботи, а вже тоді додати гарний дизайн.

Наполягай на ідеальному виконанні не важливих завдань. Порада №5.

Наполягай на ідеальному виконанні неважливих завдань. Переробляй дрібні помилки в неважливих завданнях знову й знов. Якщо робиш помилки — то такі, які дуже важко виявити.

Наприклад, це може бути проблемою недосвідчених менеджерів проекту: розробили новий функціонал і починають його доводити до ідеалу, без урахування скоупу, таймлайну та звітом перед клієнтом.

Використовуйте девіз стартапів — “Done is better than perfect”. Краще добре, ніж ідеально!

Схвалюй поганих виконавців. Порада №6.

Схвалюй поганих виконавців, надавай їм підвищення, бонуси. Дискримінуй гарних виконавців.

Якщо треба щось розвалити, це добра інструкція! 😄 Можна помітити, якщо не надавати гарний конструктивний фідбек для команди, то це може розвалити даний ланцюжок. Попередні поради більш персональні, а порада №6 про майже всю команду, тому треба дуже обережно виконувати свої дії.

Не використовуй бібліотеки, або код, який вже написан. Порада №7.

Не використовуй бібліотеки, або код, який вже написан. Нову задачу почни робити з чистого аркушу, щоб зʼявилась дуплікація коду. Роби те ж саме з документацію по проекту та процесам.

Якщо так робити, то коду стане у рази більше. А чим більше коду, то й пропорційно більше тестування, рефакторинг буде складніший, виправляти помилки доведеться не в одному місці, а в багатьох. Якщо це про документацію та процеси, то треба тримати все в одному місці, гігієнічно, щоб всі мали доступ, щоб був один універсальний документ для того, щоб не йти до 5 документів і не робити ctrl-c, ctrl-v.

У подкасті Програмісти та бібліотеки — від любові до ненависті за один реліз розповідається про бібліотеки, необхідність та користь від них.

Не відповідайте на повідомлення одразу. Порада №8.

Не відповідайте на повідомлення одразу. Зачекайте наступного дня або тижня.

Або напиши “привіт” і просто зникни! 😄

Обов’язково по процесам має бути прийнятий норматив відповіді — наприклад, 1 година, статуси в Slack.

Роби pull-requests дуже великими, щоб їх було важко перевіряти. Порада №9.

Програмісти, відійдіть від екранів! Робіть пул-реквести дуже великими, щоб їх було важко перевіряти.

Історія з життя:

Проходив демо-реліз, розробник розробив функціонал, але у тому ж самому бранчі він розробив нову функцію, яка не входить в скоуп цього релізу. Попередні функції були протестовані і менеджер проекту спитав у розробника про готовність усіх фіч для релізу. Розробник вилив на stage весь бранч з гарними фічами та не з протестованими функціями одночасно. Таким чином він зломав демо, тому що через велику кількість помилок замовник не прийняв роботи й по новим функціям.

Гарне рішення: Потрібно було протестовані функції залити на stage, а не протестовані функції залишити в develop-гілці репозиторію.

Скаржиться менеджменту на інших співробітників. Порада №10.

Скаржиться менеджменту на інших співробітників.

Project Manager відіграє роль психолога так чи інакше. Та хочеться переводити таку комунікацію в конструктивні рішення, тобто приходити з пропозиціями “а як тобі буде краще?”, “що треба зробити?”.

Ігноруйте заклики менеджменту робити інновації і колег про допомогу. Порада №11.

Ігноруйте заклики менеджменту робити інновації. Ігноруйте заклики колег про допомогу.

Якщо людина не знає як це зробити, де це пошукати, як з цим впоратися та проходить декілька днів і ви витратили час в нікуди. Це також маркер саботажу на роботі! Обов’язково повинен знайтися більш досвідчений співробітник, який може допомогти та проконсультувати.

Підсумки

Це справді була рекомендація, як саботувати роботу! Рекомендації, щоб такого не було:

  1. По-перше, не робіть так! Хочеться, щоб було бачення продукту, фокус на корисних послугах, команда відчувала, що може розраховувати на допомогу, клієнт довіряв результатам.

  2. Саботаж на роботі може бути усвідомленим або неусвідомленим. На практиці, більшість випадків неусвідомлені. Але якщо ви бачите подібне, то намагайтесь розібратися чому так і вирішити.

Контакти

Viktoria Kopeykina, HR manager, Design and Test Lab

095 033-17-78, office@dnt-lab.com

Send CV