Найпоширеніші проблеми студій

Критерієм успішності роботи студії може бути, як мінімум, здатність якісно та своєчасно виконувати замовлення і отримувати належний прибуток, а як максимум визнання студії в своїй країні і за кордоном. Але не завжди відбувається так, як хотілося й рано або пізно виникають проблеми:

Втрата № 1  Незавершена або не здана робота.

  • Незданий дизайн.
  • Недоверстанний макет.
  • Непротестований код.
  • Незапрограмовані вимоги.

Pesochnye-chasy-Awaglass-s-mylnoy-penoy-vmesto-peska
Чим більше недоробленої роботи у вашій компанії, тим більше ви ризикуєте прогоріти.

Знову ж таки, якщо подивитися з точки зору замовника: недороблена робота не приносить ніякої користі. Вона йому не потрібна.

Що робити: Всіма правдами і неправдами намагайтеся скоротити кількість незданої, одночасно виконуваної роботи. Краще довести один проект до кінця і потім приступити до наступного, ніж взятися за 4-5 і робити їх паралельно.

Втрата №2 – Повторне обговорення одного і того ж питання, до якого вже прийнято рішення (Relearning).

47-1

Наприклад, ви прийшли до висновку, що не погано б використовувати в студії якусь систему контролю версій. Ретельно вивчили питання. Зібралися, обговорили плюси і мінуси. Вирішили, що краще – GIT або SVN. Повністю розібралися в питанні. І як стандарт у себе вирішили прийняти SVN. Впровадили як стандарт. Навчилися. Почали використовувати.

І ось через півроку працівник каже: «А чому ми використовуємо SVN, а не GIT?  GIT – це круто тому, що < якийсь аргумент> ». Насправді через півроку ніхто вже не пам’ятає, чи то ці аргументи вже розглядалися (і ви разом дійшли до висновку про їх недоліки), чи то ці аргументи ви пропустили при обговоренні. Доводиться вивчати питання повторно. Витрачати час, замість того, щоб робити гроші.

Що робити: Фіксувати не тільки рішення, а й контекст й аргументи щодо прийнятих рішень. Тут добре працюють діаграми (Root Cause-аналіз, Mind Map, A3-аналіз). Знайти баланс між переглядом своїх процесів/засобів розробки та дотриманням прийнятих стандартів.

Втрата №4 - Зволікання погоджень.

taym-menedzhment

  • Очікування узгодження із замовником;
  • Внутрішні узгодження;
  • Даремні наради, обговорення та особисті зустрічі;

Дуже актуальна втрата – очікування. Поки замовник узгодить макет на 3-х рівнях. Поки затвердить тексти. Поки юрист зволить прислати правочки до договору.

Особливо багато ресурсів відлітає на особисті зустрічі з дріб’язковим питанням. Часто, для того щоб не приймати рішень – на наради запрошується якомога більше людей. Переміщення тіл по місту на зустрічі для обговорення «якого розміру у нас будуть букви» – надзвичайно дороге задоволення, але мало хто реально рахує, скільки коштує зібрати і провести одну таку зустріч. Домовленості не фіксуються, обговорення відлітають у порожнечу.

Що робити: скоротити кількість залучених до проекту людей до мінімуму. Приймати рішення максимально оперативно. Скоротити кількість нарад та особистих зустрічей. Якщо вже і проводити збори – мати чіткий регламент, фіксувати і чітко дотримуватися домовленості.

Втрата № 5 - Баги.

brainstorming-600x257

 

Що важливо знати про баги: чим пізніше дефект знайдений, тим він дорожчий. Якщо ви, припустимо, програміст, і знаходите та фікс баг самі та відразу – це коштує дешево. А от якщо його знаходить клієнт – то це вже загрожує наслідками.

Що робити: як можна більш раннє тестування. На великих проектах – автоматичні тести. Чіткі стандарти . Регулярна практика. Наставники для новачків.

Втрата №6 -  Втрати при передачі проекту

mozgovoi_shturm_b

Втрати:

  • Відповідальності;
  • Знань;
  • Проектів;
  • Дій.

Кожен раз при передачі проекту відбувається втрата часу й інформації: вербальної і невербальної. Втрата інформації в підсумку призводить до помилок, переробкам і знову ж – витратам часу. Особливо відчутні втрати при передачі проектів з одного дизайнера проектів на іншого, або при зміні програміста в проекті. І самий складний випадок – зміна відповідальної особи на стороні клієнта.

Що робити: мінімізувати кількість залучених в проект людей до необхідного мінімуму. Виключити передачу проектів між командами та відповідальними особами.

Втрата №7 - Перехід  між великою кількістю різних завдань.

photo

Людський мозок погано пристосований до багатозадачності. Поки ми переключаємось з проекту на проект – ми втрачаємо контекст завдання. На відновлення контексту потрібно від 15 хвилин до півгодини. Це чисті втрати.
До речі, якщо працівник здатний перемикати контекст швидко – це означає, що в ньому сильні задатки менеджера.

Що робити: менше багатозадачності.

Втрата №8 – Нереалізований творчий потенціал працівників

vincent_van_no_by_sagittariusgallery-d5y4h31

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

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

 

 

 

 

 

Marta Hudz