Рецепты спасения - в диалоге специалистов белорусской медиакомпании TUT.BY, состоявшемся в Минске, на конференции Hacks/Hackers Minsk (#hhminsk) 3 апреля 2015 года.
 |
Для начала сотрудничества неплохо бы устроить переговоры, составить ТЗ, найти переводчика, договориться о терминологии. И по возможности не ругаться
(Источник фото - StockSnap.io)
|
По плану доклад об особенностях совместной работы журналистов и айтишников должен был делать один спикер, а вышли двое. Далее происходившее напоминало пьесу, действующими лицами (и одновременно докладчиками) которой были:
- Журналист (Hack) - Елена Шалаева, выпускающий редактор
- IT-специалист (Hacker) - Александр Белковец, менеджер по информационным технологиям.
Проблемы
Елена [ремарка - с оптимизмом и верой в человеческий разум] интересуется:
- Они [айтишники] должны делать то, что мы им скажем. Не спорить, не огрызаться. Например, мы просим их сделать нам шаблон для спецпроектов. А они говорят: это сложно, оно будет плохо работать. Мы настаиваем, они нам делают, и оказывается, что это действительно плохо работает.
- Второй аспект: плохое взаимопонимание, нечеткая постановка задач, одни и те же слова мы понимаем по-разному.
- И что делать?
Решение № 1: Посредник
- Самый простой способ облегчить взаимодействие с внутренними клиентами и разработчиками - это переводчик (человек-посредник), который может иметь какое-то техническое образование, должен уметь общаться с людьми, иметь терпение.
Его задача - узнать, что хочет одна сторона, и потом другой стороне это объяснить на понятном ей языке (технической документации, например, или в терминах, которые понятны разработчикам). И наоборот.
Такой человек необходим на первых этапах в коммуникациях, когда стороны друг друга не понимают вообще. И его роль уменьшается, сводясь постепенно к нулю, когда люди учатся ставить грамотно задачи и принимать результат.
Елена: Насчет человека-переводчика. Я считаю, что этот человек должен работать в редакции (= быть на стороне журналистов), поскольку редакционные процессы существенно отличаются от рабочих процессов в отделе разработки. Хотя все пишут, что это должен быть человек с техническим бэкграундом и опытом. Но я считаю, что он прежде всего должен понимать, чего хочет заказчик (= редакция).
Александр: Эту роль может выполнять человек с любой стороны. Обычно это проект-менеджер.
Решение № 2: Техзадание
Александр:
- Первое, о чем должен подумать заказчик, это зачем/для чего это все делается, как согласовывается с общей стратегией, каких именно целей мы пытаемся достичь (повысить посещаемость, трафик, время на сайте и т.д.).
Что мы обязательно должны написать в ТЗ:
- Цель
- Критерии приемки (как определить, что задача выполнена)
- Что именно надо сделать
Акцент на слове Что!
Не Как делать надо объяснять в постановке задачи, а именно Что сделать
Александр предупреждает Чего делать не надо
- Показывать - сделайте нам вот так, но только немного по-другому. Пока вы будете прояснять, что значит "по-другому", на переписку и разговоры уйдет столько же времени, сколько вы потратили бы на составление оригинального ТЗ. А когда надо задействовать еще один отдел для решения задачи, то в переписке можно вообще утонуть. Плюс еще и ответственность размывается, поскольку инициатор часто не может принять решение из-за этого потока писем и обсуждений. В итоге - бесполезная трата времени и ресурсов.
- Очень важна связь между разработчиками и заказчиками. Все должны понимать, что они - часть одного проекта, команда должна быть мотивирована. Ну, и не надо устраивать истерики и ругаться.
Что делать надо? Быть взаимовежливыми, учиться и учить слова
Александр: Нет, не должен. Это не его задача. Он должен просто ставить задачу и рассказывать Что Надо Сделать. А разработчик уже решит Как это сделать.
Елена: Я пишу задание и спрашиваю: "Ребята, все понятно?" Они мне говорят, что, мол, вот это и это напиши еще, а вот это перепиши заново, потому что непонятно, что ты имеешь в виду. И потихоньку процесс наладился.
Александр: Да, это в общем-то процесс обучения. Вначале вам приходится объяснять все на пальцах. Но со временем все приходит в норму. Это проверено на многих людях, которые таким образом чудесно научились ставить задачи.
Елена: Надо также понимать, что не стоит дергать разработчика, когда он делает серьезную задачу. Лучше договариваться о каком-то конкретном времени, собираться за чашкой чая или в переговорной...
Выходы, которые можно предложить для решения проблемы отсутствия взаимопонимания, они - совершенно универсальные, т.е. подходящие для решения любых конфликтов.
В процессе общения с разработчиками журналисты начинают понимать, что первые - это не ребята в растянутых свитерах с грязными волосами, а образованные и интеллигентные товарищи, которые могут предложить такой хороший вариант, который никогда не придет журналисту в голову.
Еще один выход - составлять глоссарий терминов, которые использовать для описания задачи. Чтобы одни и те же слова понимались одинаково. Говоря, например, "отступ" или "пробел", журналисты и айтишники имеют в виду совершенно разные вещи.
Под занавес
Елена и Александр единогласно призывают: Уважайте и любите коллег!
The End
P.S. Добавлю от себя
Я, будучи по образованию инженером, сравнительно легко разобралась, как компьютером пользоваться, и даже перевела все делопроизводство конторы, в которой тогда работала, в электронный формат, избавившись навеки от громыхающей пишущей машинки.
Потом я сменила работу, и на новом месте меня угораздило вскользь упомянуть, что я немного смыслю в компьютерах. В общем, человек, который звался там техническим директором, в эту минуту возненавидел меня как-то по-особому люто. В общем, я радовалась, что контактировать по работе нам почти не приходилось.
Оказавшись в медиакомпании и будучи журналистом, я гораздо чаще встречалась с неприятием себя в качестве разумного существа со стороны разного рода айтишников, чем будучи редактором. А на посту главреда это отношение, помнится, и вовсе чудесным образом нивелировалось. Так что этот нюанс, на мой взгляд, стоило бы добавить к дружеским встречам под плюшки и рюмку чая, посвященным поискам/созданию общепонятного языка и мучительному воспитанию толерантности.
Другими словами, я бы этого человека-переводчика (= проект-менеджера) наделила высоким статусом и полномочиями. Чтобы его уважали обе стороны
А остальное - да, разумно и достойно развития/воплощения в управленческий процесс. В последнем случае (когда, например, производство медиапроектов в редакции поставлено на поток) без "переводчика" и вовсе можно обойтись, разработав стандартную процедуру: что, зачем и кто делает/контролирует.
Разумеется, как это раньше формулировали, "в теплой и дружественной обстановке взаимопонимания и сотрудничества" :-)
Ободряет и тот факт, что журналистам стало проще с развитием цифровых технологий и появлением массы онлайн-сервисов/приложений (читайте посты на странице Tools) с понятными и простыми пользовательскими интерфейсами. Бери готовый продукт и делай свой проект! И часто в процессе приходится открыть то учебник по HTML, то по веб-дизайну, то про JS что-то почитать... И если бы в редакциях эти усилия замечали и отмечали, это бы здорово мотивировало наиболее любопытных (= профессиональных) пишущих сотрудников.
Это так, к слову.
