«Недокоммуникация» как один из признаков украинского аутсорсинга

Щодня в своїй роботі я спілкуюся з різними людьми - клієнтами, розробниками, QA-спеціалістами, технічних та нетехнічних персоналом на стороні клієнтів. Дуже важливою, а можливо і головною, місією фахівця в його щоденній роботі є те саме, що на Заході описується фразою to make customer happy , яка включає в себе досить багато складових, необхідних для досягнення успіху. Комфорт клієнта при роботі з командою грає не останню роль в цих списку.

Аналізуючи роботу проектних команд, а також проводячи аудити проектів і процесів в IT-компаніях, я зміг визначити для себе список проблем, при яких клієнт не відчуває комфорту при роботі з командою чи розробником. Однією з основних проблем, яка змушує деяких клієнтів відмовитися від послуг вітчизняних розробників, - отстутствие якісних моделей спілкування і Репортинг, очікуваних замовником на старті роботи.

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

Відповіді на питання

Дуже часто, задавши питання, клієнт отримує у відповідь фразу, яка мало про що йому говорить. Будучи людиною, зацікавленим у своєму проекті, і намагаючись зрозуміти більше, він починає з'ясовувати деталі та листування затягується на 10-15 імейлів. У результаті поглинена безліч корисного часу, на яке були заплановані інші завдання. Рішення проблеми, насправді, дуже просте: закладайте більше описів в свою першу відповідь, намагайтеся бути максимально простими у викладі і пам'ятайте, що не кожен замовник має технічний бекграунд і буде в змозі вас зрозуміти.

Якісний Репортинг

Клієнти дуже люблять бачити прогрес як в межах ітерації, так і в межах окремо взятої задачі. 10-15 хвилин роботи в день над невеликим звітом за завданнями, які були зроблені і які ви плануєте зробити найближчим часом, не стануть для вас великою проблемою. Клієнт же буде спокійний, бачачи, що команда працює і забезпечує певний результат.

Реакція на проблеми

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

Управління змінами

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

Документація

Досить суперечливий з точки зору розробників, але дуже важливий пункт, на який звертає увагу замовник. Будь то специфікація, технічна документація, користувацька інструкція або навіть коментарі коду - це те, що часто показує налагоджений рівень процесів на проекті і, з його точки зору зовнішніх консультантів, рівень розробників. Варто пам'ятати, що не всі замовники розуміють важливість гарного коду, покритого тестами. У разі відсутності документації під час ревью проекту зовнішніми консультантами це буде відзначено як проблема, яка повинна бути виправлена. Рішення проблеми більш ніж просте - писати і оновлювати цю документацію, додаючи необхідний час до завдань або винести це як окрему задачу в ітераціях.

Підсумок

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

Опубліковано: 01/12/11 @ 10:23
Розділ Різне

SEO Блог