Как журналисты и IT-специалисты могут сработаться и остаться в живых

Рецепты спасения - в диалоге специалистов белорусской медиакомпании TUT.BY, состоявшемся в Минске, на конференции Hacks/Hackers Minsk (#hhminsk) 3 апреля 2015 года.

Для начала сотрудничества неплохо  бы устроить переговоры, составить ТЗ, найти переводчика, договориться о терминологии. И по возможности не ругаться

(Источник фото - StockSnap.io)

По плану доклад об особенностях совместной работы журналистов и айтишников должен был делать один спикер, а вышли двое. Далее происходившее напоминало пьесу, действующими лицами (и одновременно докладчиками) которой были:

• Журналист (Hack) - Елена Шалаева, выпускающий редактор 
• IT-специалист (Hacker) - Александр Белковец, менеджер по информационным технологиям.

Проблемы

Елена [ремарка - с оптимизмом и верой в человеческий разум] интересуется:  

1. Они [айтишники] должны делать то, что мы им скажем. Не спорить, не огрызаться. Например, мы просим их сделать нам шаблон для спецпроектов. А они говорят: это сложно, оно будет плохо работать. Мы настаиваем, они нам делают, и оказывается, что это действительно плохо работает. 
2. Второй аспект: плохое взаимопонимание, нечеткая постановка задач, одни и те же слова мы понимаем по-разному. 
3. И что делать? 

Решение № 1: Посредник

Александр [ремарка - с видом знающего и тоже верящего в человеческий разум человека] отвечает:

- Самый простой способ облегчить взаимодействие с внутренними клиентами и разработчиками - это переводчик (человек-посредник), который может иметь какое-то техническое образование, должен уметь общаться с людьми, иметь терпение. 
Его задача - узнать, что хочет одна сторона, и потом другой стороне это объяснить на понятном ей языке (технической документации, например, или в терминах, которые понятны разработчикам). И наоборот. 
Такой человек необходим на первых этапах в коммуникациях, когда стороны друг друга не понимают вообще. И его роль уменьшается, сводясь постепенно к нулю, когда люди учатся ставить грамотно задачи и принимать результат.

Елена: Насчет человека-переводчика. Я считаю, что этот человек должен работать в редакции (= быть на стороне журналистов), поскольку редакционные процессы существенно отличаются от рабочих процессов в отделе разработки. Хотя все пишут, что это должен быть человек с техническим бэкграундом и опытом. Но я считаю, что он прежде всего должен понимать, чего хочет заказчик (= редакция).

Александр: Эту роль может выполнять человек с любой стороны. Обычно это проект-менеджер. 

Решение № 2: Техзадание

Редакции при постановке задач IT-отделу следует вести себя как заказчик.

Александр:

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

Что мы обязательно должны написать в ТЗ: 

• Цель 
• Критерии приемки (как определить, что задача выполнена) 
• Что именно надо сделать 

Акцент на слове Что! 

Не Как делать надо объяснять в постановке задачи, а именно Что сделать

Александр предупреждает Чего делать не надо

1. Показывать - сделайте нам вот так, но только немного по-другому. Пока вы будете прояснять, что значит "по-другому", на переписку и разговоры уйдет столько же времени, сколько вы потратили бы на составление оригинального ТЗ. А когда надо задействовать еще один отдел для решения задачи, то в переписке можно вообще утонуть. Плюс еще и ответственность размывается, поскольку инициатор часто не может принять решение из-за этого потока писем и обсуждений. В итоге - бесполезная трата времени и ресурсов. 
2. Очень важна связь между разработчиками и заказчиками. Все должны понимать, что они - часть одного проекта, команда должна быть мотивирована. Ну, и не надо устраивать истерики и ругаться.

Что делать надо? Быть взаимовежливыми, учиться и учить слова

Елена: Возникает вопрос - должен ли журналист быть технически образован?
Александр: Нет, не должен. Это не его задача. Он должен просто ставить задачу и рассказывать Что Надо Сделать. А разработчик уже решит Как это сделать. 

Елена: Я пишу задание и спрашиваю: "Ребята, все понятно?" Они мне говорят, что, мол, вот это и это напиши еще, а вот это перепиши заново, потому что непонятно, что ты имеешь в виду. И потихоньку процесс наладился.
Александр: Да, это в общем-то процесс обучения. Вначале вам приходится объяснять все на пальцах. Но со временем все приходит в норму. Это проверено на многих людях, которые таким образом чудесно научились ставить задачи.

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

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

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

Под занавес

Елена: Обе стороны должны быть терпимы к критике и воспринимать адекватно экспертное мнение. 

Елена и Александр единогласно призывают:  Уважайте и любите коллег!

The End

P.S. Добавлю от себя

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

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

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

Оказавшись в медиакомпании и будучи журналистом, я гораздо чаще встречалась с неприятием себя в качестве разумного существа со стороны разного рода айтишников, чем будучи редактором. А на посту главреда это отношение, помнится, и вовсе чудесным образом нивелировалось. Так что этот нюанс, на мой взгляд, стоило бы добавить к дружеским встречам под плюшки и рюмку чая, посвященным поискам/созданию общепонятного языка и мучительному воспитанию толерантности. 
Другими словами, я бы этого человека-переводчика (= проект-менеджера) наделила высоким статусом и полномочиями. Чтобы его уважали обе стороны конфликта проекта.

А остальное - да, разумно и достойно развития/воплощения в управленческий процесс. В последнем случае (когда, например, производство медиапроектов в редакции поставлено на поток) без "переводчика" и вовсе можно обойтись, разработав стандартную процедуру: что, зачем и кто делает/контролирует. 
Разумеется, как это раньше формулировали, "в теплой и дружественной обстановке взаимопонимания и сотрудничества" :-)

Ободряет и тот факт, что журналистам стало проще с развитием цифровых технологий и появлением массы онлайн-сервисов/приложений (читайте посты на странице Tools) с понятными и простыми пользовательскими интерфейсами. Бери готовый продукт и делай свой проект! И часто в процессе приходится открыть то учебник по HTML, то по веб-дизайну, то про JS что-то почитать... И если бы в редакциях эти усилия замечали и отмечали, это бы здорово мотивировало наиболее любопытных (= профессиональных) пишущих сотрудников. 

Это так, к слову.