Продолжается опрос по языкам программирования. Уже собрано почти 7000 ответов. Заполняйте анкету!
×Закрыть

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

Ежедневно в своей работе я общаюсь с различными людьми — клиентами, разработчиками, QA-специалистами, техническим и нетехническим персоналом на стороне клиентов. Очень важной, а возможно и главной, миссией специалиста в его ежедневной работе является то самое, что на Западе описывается фразой to make customer happy, которая включает в себя достаточно много составляющих, необходимых для достижения успеха. Комфорт клиента при работе с командой играет не последнюю роль в этим списке.


© CCBImages

Анализируя работу проектных команд, а также проводя аудиты проектов и процессов в IT-компаниях, я смог определить для себя список проблем, при которых клиент не чувствует комфорта при работе с командой или разработчиком. Одной из основных проблем, которая заставляет некоторых клиентов отказаться от услуг отечественных разработчиков, — отстутствие качественных моделей общения и репортинга, ожидаемых заказчиком на старте работы.

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

Ответы на вопросы

Очень часто, задав вопрос, клиент получает в ответ фразу, которая мало о чем ему говорит. Являясь человеком, заинтересованным в своем проекте, и пытаясь понять больше, он начинает выяснять детали и переписка затягивается на 10–15 имейлов. В результате поглощено множество полезного времени, на которое были запланированы другие задачи. Решение проблемы, на самом деле, очень простое: закладывайте больше описаний в свой первый ответ, пытайтесь быть максимально простыми в изложении и помните, что не каждый заказчик имеет технический бекграунд и будет в состоянии вас понять.

Качественный репортинг

Клиенты очень любят видеть прогресс как в пределах итерации, так и в пределах отдельно взятой задачи. 10–15 минут работы в день над небольшим отчетом по задачам, которые были сделаны и которые вы планируете сделать в ближайшее время, не станут для вас большой проблемой. Клиент же будет спокоен, видя, что команда работает и обеспечивает определенный результат.

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

В случае непредвиденной проблемы, описанной клиентом, получив уведомление о проблеме, разработчик первым делом начинает проверять, что произошло. Сообщает же об этом клиенту, лишь обнаружив проблему, а иногда делает это уже и после того как с ней справился. Здесь заведомо заложен риск того самого некомфортного состояния клиента. Сообщив об ошибке системы, ведущей к некорректной работе, заказчик остается не в курсе того, что происходит. Поэтому первое, что должен сделать человек, получивший оповещение о проблеме, — это сообщить, что уведомление получено и проблема получила соответствующее внимание. В ходе работы над возвращением системы в нормальный режим разработчик должен давать клиенту регулярные короткие отчеты, сохраняя тем самым его спокойствие. Игры «в молчанку» дадут лишь обратный результат.

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

Многие сталкивались с тем, что заказчики часто просят поменять или добавить некоторый функционал, внося тем самым изменения к запланированному списку задач. Всегда стоит помнить, что заказчик почти никогда не видит в этом изменений к заранее намеченному плану. Желание разработчика помочь клиенту, как правило, вызывает множество позитивных эмоций со стороны клиента, но всегда стоит помнить о том, что лучше заранее объяснить почему это передвинет сроки, чем объяснять потом почему запланированный набор задач не был сделан вовремя.

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

Достаточно противоречивый с точки зрения разработчиков, но очень важный пункт, на который обращает внимание заказчик. Будь то спецификация, техническая документация, пользовательская инструкция или даже комментарии кода — это то, что часто показывает отлаженный уровень процессов на проекте и, с его точки зрения внешних консультантов, уровень разработчиков. Стоит помнить, что не все заказчики понимают важность красивого кода, покрытого тестами. В случае отсутствия документации во время ревью проекта внешними консультантами это будет отмечено как проблема, которая должна быть исправлена. Решение проблемы более чем простое — писать и обновлять эту документацию, добавляя необходимое время к задачам или вынести это как отдельную задачу в итерациях.

Итог

Многие команды и разработчики учли это в своих процессах, многие считают эти и другие пункты важными для будущего улучшения процессов, некоторые не видят в этом смысла. Как использовать эти советы и использовать ли их — сугубо личное дело каждого, но главное к чему мы все должны стремиться — это делать завтра лучше, чем сегодня, в том числе и в работе над проектами и в общении с теми, от кого эти проекты зависят.
👍НравитсяПонравилось0
В избранноеВ избранном0
Подписаться на автора
LinkedIn

Похожие статьи




Підписуйтесь: SoundCloud | Google Podcast | YouTube

51 комментарий

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

В статье озвучены важные проблемы. Их можно решать по-разному. Одни решения лечат следствия, другие — причины. Третьи же только усиливают проблемы...

К примеру, качественный репортинг можно делать разными способами: можно оповещать заказчика о технических проблемах, можно делать демонстрации фич, можно отсылать имейл с новостями по проекту, можно звать на daily meeting... Но что из этого лечит причину, а что лишь ее вуалирует? Причины у необходимости репортить обычно такие: недоверие заказчика к команде и тенденция к тотальному контролю. Увы...

Микроменеджмент со стороны заказчика обычно только усиливает его паранойю — чем больше он контролирует и чем больше видит, тем больше хочет вмешиваться и влиять.

Но с другой стороны: если заказчик получает обещанные ему фичи во время и с адекватным качеством, будет ли он микроменеджить на уровне задач и работников? Или он доверится команде и теперь посвятит свое ценное время более важным вещам — работе с пользователями, заинтересованными лицами и scope-management.

Я бы посоветовал — учиться разделять внутреннюю кухню команды (технические вопросы) от продуктовых (бизнес) вопросов, которые в компетенции заказчика. Большинство проблем на моем опыта возникают именно из-за того, что заказчик сидит на двух стульях.

Мои советы:

1) Сделайте прогресс видимым
a) проводите регулярные демонстрации фич и версий продукта (не реже, чем раз в две недели)
б) заведите такой тул, который разграничивал бы кухню от клиентов — тул, в котором заказчику был бы виден статус по фичам, без деталей о задачах и работниках

2) Научите заказчика управлять изменениями и скоупом
а) научите заказчика концепции релизов с фиксированным временем и плавающим скоупом, в который вы вместе будете целиться
б) научите заказчика визуализировать прогноз по скоупу, который попадает в релиз (инструмент release burndown chart)
в) регулярно садитесь с заказчиком для уменьшения и уточнения скоупа работ в релизе (хорошее время для этого демонстрация версии)

3) Делайте все, чтобы заказчик ездил к вам. Так часто, как это возможно
а) уточняйте цели и видение проекта
б) во время его приездов планируйте релизы
в) обсуждайте улучшения процесса

Эти советы одинаковы как для аутсорсинговых команд, так и для стартаперов.

заказчики бывают разные как и проекты, некоторым мало agile, скрама и т.д. им подавай ежедневный репортинг в тулзе, плюс почтой с планами на завтра и им невдомек что до конца спринта куча времени, а они не должны вроде менять скоуп каждый день)

Хороший, простой и ясный список. Особенно подчеркнул бы

Одной из основных проблем, ... , — отстутствие качественных моделей общения и репортинга, ожидаемых заказчиком на старте работы.

потом вы можете выяснить или договориться что не нужна эта документация, и репорты не нужны по 15 мин в день — может 5 мин в неделю общения с тимлидом покроет все с головой. Но это будет потом. А сейчас у комманды и заказчика разое видение процесса, даже если и кажется что нет.

Повторяющееся наблюдение — программисты (ну как и все люди) четко делятся на аудиалов и визуалов. Первые недоумевают, зачем писать письма и отчеты, ведь можно позвонить и все сказать. Вторые при одном только виде телефона вздрагивают, зато с удовольствием пишут отчеты. Похоже, выбирая фирму или подбирая сотрудника, надо обращать на это внимание.

Почему я нигде не могу скачать Microsoft Audial Studio ?

Есть два типа разработчиков: одни думают, что им платят деньги за то, что они пишут код. Другие — что им платят за то, чтобы они make customer happy.

Соответственно первым список советов ни к чему, а вторые его уже более-менее знают :)

Тем не менее, отличный пост :)

Есть два типа разработчиков: одни думают, что им платят деньги за то, что они пишут код. Другие — что им платят за то, чтобы они make customer happy.

Правильно — должно быть 2 типа сотрудников: одни пишут код, другие make customer happy. Разделение труда — его еще в каменном веке придумали.

Код, даже качественный, даже вызывающий ух-ты у коллег, и половины рунета — нах** сам по себе не нужен — пока, в каком либо виде он не продан.
Так вот даже программистам пишущим код стоит бы знать, с какой целью они его пишут — самоудовлетвориться, или — с бизнес-целью. То есть последующей его «продажи».
Другое дело, что нередко менеджеры разных уровней не объясняют что и как. В итоге программисты нередко как дели малые, в их понимании «еда берется из холодильника», а денежка на мороженное из кошелька папы.
Собственно это единственный случай, когда я признаю нужность понимания всеми сотрудниками миссии компании — to make customer happy. И даже не в качестве мотивации. А чтобы не было лишнего шума когда вместо супер-бупер фичи, вдруг дают указание доваять, допилить мелкую и марудную хрень. Потому что вот именно эту хрень и хочет тот кто денежку платит.
Я не знаю как западные программисты, но годами уже отшлифовал такое взывание к нашим:
«Не нужна твоя резная ножка от венецианского стула! Пользователю сидеть не на чем, сделай млин табуретку. Пусть даже о трех ногах, и с занозами.» А то начинающие программисты сплошь помешаны на «быстродействии» своих программ, циклы оптимизируют, чуть покруче — о «качестве», а в итоге индийцы присаживают пользователей на свои табуретки.

А то начинающие программисты сплошь помешаны на «быстродействии» своих программ, циклы оптимизируют, чуть покруче — о «качестве», а в итоге индийцы присаживают пользователей на свои табуретки.

Да у нас ИТ только и развивается потому что мы не как индусы. «Формошлепов», которые будут табуретки клепать в индии могут за день 1000 найти — нам с ними не тягаться. Если единственная цель это make customer happy — тогда и качество кода получается «индийское».

Нашит клиенты аутсорсят нам потому что мы сначала думаем — а потом еще и стараемся сделать лучше. И в результате получается не «табуретка с занозами» а вполне себе приличный стул. А иногда потом даже хвалят за то что подумали — и не стали делать какую-нибудь безумную чушь придуманную клиентом.

А иногда потом даже хвалят за то что подумали — и не стали делать какую-нибудь безумную чушь придуманную клиентом.

делание безумной чуши — никак не to make customer happy. А вот как раз предвидение проблем клиента, вместо него, и есть ориентация на его happy.

Так что вы почему-то пытаясь возразить только подтвердили:
ключ к успеху когда цель — to make customer happy.

Неважно кто придумал бесполезную вещь, программист или сам заказчик.

Нашит клиенты аутсорсят нам потому что мы сначала думаем — а потом еще и стараемся сделать лучше.

Лучше для кого? С каких позиций оценивается что лучше а что хуже?

И второй, важный момент для меня пока малопонятный — если мы такие умные, то почему нас аутсорсят, а не заказывают нам работу?

Кто ведет проект, кто ищет баланс между сроками, фичами и качеством? Кто берет на себя ответственность в конце концов — ослушаться заказчика, зная что он понапридумал себе ерунды, и самого же греть «несбалансированное» приложение не будет? Кто перекраивает требования?

ерунда.
Все ненавидят эти ежедневные репорты и пишут туда х#йню из под палки.
Если продукт овнер болеет за свой проект надо больше участвоввать в его жизни — митингах и тп а не свешивать это на тупого как пробка специалиста по заполнениею воркин hours.

Один короткий бизнес трип сможет закрыть заказчику столько проблем сколько он будет решать через погоньщиков пол года...

вообщето репортингом толжен заниматься ПМ или ТЛ, тогда это действительно часть тех.процесса. а грузить прогеров — глупость, всеравно низкоуровневые репорты никто не читает

Вообще много аутсорсеров работает в режиме XP, где продукт нужен уже вчера, и чтоб работал и об отчетах и документации думают в последнюю очередь, как элемент причесывания продукта. Если ядро команды стабильное(это самый важный аспект), и ПО выполняет свои задачи, заказчику наплевать на покрытие тестами и красивый код. Другое дело, если вы подрядчик «оборонки», там спецификации, документация и чрезмерное тестирование объективно, но такие вещи на аутсорс не отдают.

Для XP конечно в принципе тесты и доки не нужны, но XP не работает на больших командах.

ИМХО, проект более 10 человек без тестов и документации (да хотя бы wiki) обречён на медленную и мучительную смерть.

Евгений, маленькие проекты тоже нуждаются в документах. Процедурные доки, спецификации, планы итераций, тест кейсы, запросы на изменения, риск логи и т.д. — это все то, что плотно защищает команду. Элементарное увольнение сотрудника не должно превращаться в длительный хендовер и бессоные ночи для нового человека в команде (другой вопрос, что не каждый прочтет эти доки досконально).
Опять таки, есть понятие получения инвестиций под проект (многие задумывались о том, что за те продукты, которые мы разрабатываем, клиент должен платить деньги и брать их откуда-то?). На этапах получения новых инвестиций проект обычно проходит экспертизу через технических и нетехнических консультантов и, как я уже писал ранее, отсутствие документации посчитают «минусом».
В проекте с 10 человеками все проще — есть ПМ или ТЛ, который может взять эту часть работы команды на себя. В маленьких проектах не всегда есть фуллтаймовый менеджер, поэтому эта функция должна ложиться на плечи разработчиков.

Я уже писал ниже, если команда гомогенна, т.е с одинаковым опытом работы, то хендоверы будут отсутствовать, брать в середине проекта нового человека на старые задачи лишние потери времени для других разрабов, которые будут помогать ему вникать. В этом случае, ему лучше заниматься новыми задачами.

Конечно, вы описываете модель со всеми плюшками, когда все документировано и есть везде нужные люди, и когда нужно выбивать инвестиции. Но это все больше тянет к CMMI модели, она хорошо поддается контролю и с точки зрения менеджмента очень хороша, ПМ-ам удобно руководить. Но все-таки стоит искать что-то среднее между достаточной и необходимой формализацией (документация, логи, etc.) проекта.

А если чувак уволится посередине проекта? Его же нужно кем то заполнить.

Работу по задачам старого сотрудника берут другие разрабы, новый занимается задачами, которые меньше всего зависят от старых, и постепенно вникает в архитектуру. Если почитаешь «Вальсируя с медведями» Демарко, там кажется описывались такие ситуации, хотя может быть и в другой его книге. Конечно идеальный вариант, не дать уволиться посреди проекта. =)

Не всегда команда имеет одинаковый опыт работы, увы, а в случаях, если команда состоит из 1го человека, наличие проектной документации является обязательным.

CMMI — это не только модель, но еще и признак зрелости компании, что является преимуществом при участие в тендере на проект. Я это к тому, что проект — это не только его разработка, но и множество другой операционной деятельности связанной с ним.

Полностью согласен, просто многие компании злоупотребляют необходимостью операционной деятельности, и программистам на шею вешается толпа контролеров, которые каждые пол часа спрашивают «ну как готово?», если говорить утрировано.

Я мыслю так, что команды в 5-10 человек могут существовать, 20-25 это уже большие проблемы с организацией, куча людей которые контролируют контроль, и над ними. В обустройстве команд, имхо, лучше руководствоваться agile принципами насчет итераций, меньше лучше.

Возьмем например команду из 50 человек, ее лучше разбить на 5-6 небольших и по одному человеку из каждой команды на билды. На билдах не все любят сидеть, поэтому заменять периодически. Нет необходимости в ПМ-е для маленькой команды, я считаю это плюс, ТЛ как скрам-мастер или отец-настоятель, назвать можно как угодно решает вопросы организации ,ну, тратя максимум 30% времени.

Если разработка ведеться через тестирование, это 80% документации. Документацию в ее первозданном виде почти никто не читает, все хотят видеть пример, как это работает. Тесты решают сразу 2 задачи, описывают поведение, и проверяют работоспособность. Вторая часть документации лежит в таск менеджере (Jira например на пару с GreenHopper).Баста.

В итоге, больше времени на обдумывание и качественное кодирование.

Другое дело, если вы подрядчик «оборонки», там спецификации, документация и чрезмерное тестирование объективно, но такие вещи на аутсорс не отдают.

Boeing отдает, чо (один из самых старых клиентов Люксофта), там CMMI L5 (включая аутсорс). У инвестбанков (UBS, в частности) тоже на тестировании пунктик (объективный, т.к. любой чих может обернуться в миллионные, если не миллиардные, убытки). Так что аутсорс зело разнообразен.

Не буду подвергать сомнению, просто у боинга есть и частные проекты, но сам факт интересен, возьму на заметку.

Оборонку боинг не аутсорсит, это да. Но у них и для коммерческих проектов (777-й, 787-й) те же стандарты ведения проектов.

Очень классная статья. Спасибо. На самом деле это не везде очевидные советы и очень часто от недостатка документации / общения страдает проект, а как следствие и разработчики.

Качественный репортинг

Плохой совет. Необходимость каждый день трать 15 минут на составление однотипных отчетов (которые никто не читает) вгоняет разработчика в уныние. И плохо отражается в результате на производительности. Намного лучше, когда каждый день по телефону команда отчитывается в устной форме кому-то уполномоченному со стороны заказчика.

Остальные пункты из разряда «Капитан ОЧевидность приветствует вас, люди». Хочется только добавить, что довольно многие разрабочтики предпочитают взваливать все общение на кого-то конкретного (ТЛ, ПМ), а некоторых программистов просто лучше и не подпускать к трезвому заказчику.

Насчет «Не подпускать программистов и взваливания общения». Заказчик должен знать, что делают его люди. Иначе получается следующая картина — сам видел соственными глазами — человек хорошо работает, но заказчик об этом не знает — а так как заказчику продают в основном боди — то пусть работает, качество тут не надо. В результате человек увольняется — заказчик его не знает, потеря-то невелика :) - и все остаются в недоумении. Поэтому мой главный аргумент — необходимо избегать общения программистов с заказчиком в очень исключительных случаях и не замыкать его исключительно на ТЛ ( который в таком случае превращается в незаменимого и точку входа для заказчика — т.е можно не работать, а лишь общаться).

И как Вы это видите это общение? Пробовали эту идею — получили вариант, когда действительно талантливого программера допустили к разговору с заказчиком, у которого нету ИТ образования. В результате чуть не потеряли клиента, потому что программеры слабо понимают, что с той стороны находятся не такие, как они, а бизнес люди, которым глобально неинтересно, каким алгоритмом прогер будет решать их задачу, а которым нужен именно вижин в какие сроки, каким образом(с юзерской точки зрения) будет реализованы их нидзы и какой эффект это даст для их бизнеса.
Так что пусть заказчик лучше общается с ТЛ/ПМ, а прогеры пусть делают свою работу.

Какое-то у вас грустное описание разработчиков. Я бы сказал — кодеров.

Впрочем, был однажды случай в моей практике. Сразу оговорюсь, было это не в моей текущей компании.

Итак, насмотревшись на вялотекущее забивание на работу со стороны коллег моего тогдашнего проекта, а также наслушавшись от нашей ПМ буллшита на тему, какая мы одна команда равноправная, я спросил заказчика, а не хотят ли они уменьшить срок итерации в нашем скраме с месяца до недели.
Заказчик конечно был рад — это действительно повысило прозрачность, а людям (и мне) наконеч-то пришлось работать.
А вот реакция ПМ с нашей стороны была неожиданная. Оказывается, я должен был все телодвижения с ней согласовывать. Наш ТЛ стыдливо промолчал, хотя с ним я своими идеями как раз загодя поделился.

Вот так я за оптимизацию процесса, одобренную заказчиком, и получил, как говорится, по шапке.

Это ситуация исключительная. И она лишний раз подтверждает правило, что все хоть чуть-чуть важные вещи нужно согласовывать не устно, а в почте. Чтобы всегда было письменное подтверждение.

Бюрократия нужна, но я затем предпочел просто не работать с людьми, которые меня могут подставить.

Не обязательно подставить. Люди склонны забывать сказанное в устном разговоре. Я не про вашу ситуацию, я вообще.

Ох, какая не исключительная ситуация. Данные вещи практикуются как среди ПМов так и среди заказчиков с целью перевода стрелок, в случае фейла, и забора лавров, в случае побед. Что-то типа так «я ж так и думала сначала».

Кстати, неделя на итерацию — это как-то пугающе. У вас разве не уходит один день из пяти на подготовку к демо, проведение демо, ретроспективу и планирование?

Да, именно так. Получалось в сумме один день.
Зато остальные четыре дня мы имели четкий план с небольшими задачами детализированными с точностью до часов.

Пока был цикл месяц, то из него две, а то и три недели тратились вообще непонятно на что. В конце месяца показывать было почти нечего. А тут всё на виду.

До часов? А как же фичерпойнты?

Месяц — это в любом случае слишком много, согласен. Но мне по опыту больше всего нравится двухнедельные итерации.

ну смотря какая итерация. у нас когда то был продукт где неделя была оок — было много мелочевки и в пятницу бодро за час сдавалось клиенту. Ну и дема всегда была живая автоматом на дев сервере

Но это редкий случай и чисто спорт проект — две недели обычно комфортнее

Неделя очень стрессово, исходя из личного опыта, если в день сборки кто-то зафейлил, то начинается паника аля все пропало или забивательство. Как отписались ниже 2 недели идеально выходят. Опять таки из личного опыта, если команда гомогенна, скажем 3 разработчика с одинаковым стажем в индустрии, то можно и недельными работать. А вот мне приходилось работать в команде, где были большие разрывы в опыте и это сильно накладывало отпечаток на разработку. Многие любят говорить, что тут главное мозги и не важно сколько человек в индустрии. Однако, знание всей agile кухни изнутри немного сдвигает мозги и без опыта ну никак.

А о самодурстве ПМ ов можно складывать песни уже давно.=)

Недельные итерации оптимальны в двух случаях:
— в случае если проект зашел в кризисную фазу (пролет по срокам, например)
— на начальной фазе, если проект переводится с другой методологии управления (например с waterfall) с целью показать заказчику выгоду в увеличении контроля над деливери.
В любом случае, недельные итерации достаточно некомфортны и не являются полноценными — нет фазы нормальной стабилизации и времени для ретроспективы.

По поводу разговора ниже о длительности итерации, я предпочитаю делать 4 недельные итерации для того чтобы иметь 3-4 дня фазы стабилизации в конце итерации, которая покроет риски и даст подойти к демонстрации более спокойно.

если в день сборки кто-то зафейлил, то начинается паника

Continuous Integration рулит.

Вообще-то, да — должен был согласовывать. Разве-что у вас был ПМ, которого вы ни в грош не ставили и партизанили сами, что тоже не есть хорошо.

Может быть и так, но
1) Инициатива была одобрена ТЛ устно в стиле «неплохо бы чтобы так было».
2) ПМ вела сразу несколько проектов, так что начальник у меня был ТЛ.
3) Я задал вопрос на общем дейли митинге, на котором рассматриваются все подряд вопросы «в дружественной атмосфере равноправных участников проекта».

То ли ТЛ тормознул, то ли я поспешил.

Хотя не кажется странным, что ПМ так не нравится то, что так нравится заказчику? Да.. а так хорошо было. Народ месяц пинал, а потом рапортовал, что «мы трудимся»

Странно, что ПМ-а не интересовало то, что команда пинает. Или ПМ был только для биллинга и ресурсинга, а сам по себе проект драйвил кто-то другой?
Хотя если ПМа эта ситуация напрягла — значит скорее всего драйвил именно он.

Боюсь тут заочно категорично что-то утверждать, наверняка там была специфика. Но лучше о таких вещах договариваться заранее с ПМ-ом, он вообще-то обычно и ставится, чтобы как-то организовывать процесс.

Я полностью согласен с Олегом. Сам видел как один ТЛ всю славу присваивал себе, при полном попустительстве вышестоящего начальства. Зато чуть что, так сразу виноват разработчик. И естественно зарплату при таких раскладах даже не думают повышать!

«Тигру в цирке недодают мяса!».

Я знаю пару проектов, где не один ТЛ, а сразу два. Что они там себе присваивают — даже представлять противно!

Максимыч, ну вот зачем ты троллишь ? Сам же говоришь — тоньше надо быть, тоньше.

Телефонный разговор, если не будет записан (зафиксирован в любом виде) — пустое сотрясание воздуха. На завтра после разговора вы никому ничего не докажете, что именно это, а не то вы имели ввиду. Писать репорты, отмечать фиксы в трекере, оставлять бумажный след _всегда_ для аутсорсера — вопрос выживания.

Да, я ниже писал об этом. Нужно фиксировать результаты разговора, конечно же.

в идеале — и у нас например в свое время так неплохо получалось — поговорили-зафиксировали результаты в тикетах\ результатах митинга. Всегда писались митинг минетсы со всеми решениями+ коментировались тикеты по результатам разговора по скайпу\телефону. В таком виде иммеем профит в виде быстрых комуникаций + прикрыто одно место.

Подписаться на комментарии