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

Алексей Бородкин, Product lead в Росбанке (менеджер по продукту — отвечает за создание, продвижение и анализ новых IT-продуктов), глава Гильдии вольных проектировщиков, преподаватель Британской высшей школы дизайна и университета «Нетология». После катехизаторских курсов Патриаршего центра при Даниловом монастыре 5 лет был координатором волонтерской группы Добровольческого движения «Даниловцы» в НИИ нейрохирургии имени Бурденко. В какой-то момент совмещать работу, волонтерство и семейную жизнь стало тяжело – Алексей подыскал себе преемника и с тех пор занимается волонтерством точечно, а не системно.

До 90% всех задач можно решить с помощью таблиц

– Консультируя представителей НКО, какой вопрос вы от них слышите чаще всего?

– Простой: можно ли мне эффективно использовать digital-технологии и все связанное с интернетом для решения моих задач? Это спрашивают те, кто уже что-то попробовал и готов пробовать еще. Вторая группа вопросов от тех, кто с интернетом «на вы», им важно освоиться и понять, что это не страшно и не сложно, можно малой кровью без затрат делать разные полезные штуки, которые не требуют знания программирования.

– Можете привести пример? Что легко доступно даже тем, кто «на вы» с интернетом?

– Например, конструктор сайтов Tilda может освоить любой. Он не требует технологических навыков, там предустановлен такой набор шрифтов и элементов, что можно не разбираться ни в дизайне, ни в типографике и все равно получится хорошо. Много бесплатных функций, а платные стоят совсем недорого. Я лично не проверял, но мне говорили, что создатели Tilda идут навстречу НКО и иногда предоставляют индивидуальную скидку некоммерческим проектам. Еще пример – google-таблицы и google-документы, в них можно работать сразу нескольким людям, видеть правки, оставлять комментарии друг другу и прочее.

– Без каких цифровых решений эффективное существование НКО сейчас невозможно, на ваш взгляд?

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

После привлечения клиентов нужно учитывать, анализировать и хранить всю входящую историю – для этого нужна система учета. В базовом виде хотя бы google-таблица. Есть такая поговорка: «если не знаешь, каким цифровым инструментом пользоваться – делай таблицу». Это точно! До 90% всех задач можно решить с помощью таблиц.

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

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

Алексей Бородкин. Инвестиции в добро: как изменить мир вокруг.  TEDxYakimanka

 

Чек-лист по персональным данным

– Давайте тогда по порядку пойдем. Первое – сайт. Многим в НКО кажется, что сайт – неподъемная задача. Можно ли обойтись без сайта, только с соцсетями?

– Теоретически – да, но на практике оказывается, что соцсети хорошо подходят для информирования, но плохо – для хранения информации. А для НКО важно хранить отчеты, юридическую информацию, страницу с платежным агрегатором.

– Если говорить о google-таблицах, то возникает вопрос их безопасности: не туда нажал и таблица видна всему интернету. А в таблице-то обычно данные доноров.

– Там есть возможность давать доступ только по ссылке на конкретный почтовый ящик. Тут важнее, что если это данные доноров, то всплывает тема персональных данных и 152-ФЗ.

– Да. Один из самых частых вопросов со стороны НКО как раз об этом: как обходиться с персональными данными, и что нужно знать, чтобы не ошибиться?

– Упомянутая уже Tilda вместе с экспертом по персональным данным Максимом Лагутиным сделали очень хорошую инструкцию, чек-лист и разработали шаблон договора с пользователями – очень удобная штука. Я советуют нагуглить, просто вбейте в поиск «152 фз Тильда» (речь об этой статье и об этом конструкторе политики обработки персональных данных   – прим. автора). Важно понимать, что если НКО связывается с персональными данными, то этой темой лучше заморочиться как можно раньше. Роскомнадзор ведет себя непредсказуемо и лучше подстраховаться — сделать все необходимые формальные шаги, которые перечислены в чек-листе Tilda. Тогда можно быть более-менее спокойными.

Не стоит лезть в CRM, не освоив таблицы

– Вы упомянули в минимально необходимом наборе инструментов Trello. А можно ли в современном мире выжить, вообще не используя никакой таск-трекер?

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

– Мне кажется, все некоммерческие проекты сейчас мечтают о CRM-системе. Когда и кому пора ею обзаводиться?

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

Но я бы настоятельно не рекомендовал лезть в CRM до того, как вы прочувствовали всю логику процессов, ведя таблицы. Сначала таблицы, если в таблицах стало тесно, то можно задуматься о CRM. CRM не проще, чем google-таблицы, даже наоборот – систему сначала нужно настроить под себя, под свои процессы.

Три рейтинга надежных разработчиков

– Читатели прислали мне три кейса, которые попросили с вами разобрать. Первый как раз про CRM.  НКО захотела CRM-систему.  Нашелся подрядчик, который вроде бы хорош в этом. Но прошел год, потрачена куча денег, а CRM не построена, подрядчик ушел в тину. В чем косяк? В какой момент нужно было менять подрядчика и как распознать, что что-то не так, особенно, если ничего не понимаешь в разработке?

– Это косяк выбора подрядчика. Если ничего не понимаешь в разработке, то лезть к подрядчикам – танцевать на минном поле.

– Как быть тогда?

– Тут есть два пути. Первый – искать надежного разработчика через рейтинги. Например, Tagline, рейтинг Рунета или RUWARD, где вывешены основные игроки рынка. При выборе подрядчика важно смотреть на портфолио, обсуждать его при встрече и наблюдать, как они рассказывают о своей работе над этими проектами. Если с интересом и в деталях, видно, что горели задачей – это хороший признак.

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

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

Три книги об IT, которые стоит прочесть

– Можно ли рассчитывать на услуги такого посредника pro bono, то есть даром? И вообще насколько можно доверять разработку волонтерам?

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

– Про опытного человека – понятно. Но какие-то базовые знания и компетенции все же должны быть у заказчика? Где их взять? Какие книжки читать?

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

Три книги, которые я бы советовал прочитать: «Психбольница в руках пациентов» Алана Купера, «Разработка требований к программному обеспечению» Карла Вигерса и «Ководство» Артемия Лебедева.

Ошибайся раньше, ошибайся чаще

– Второй кейс от читателей: сайт устарел, его надо обновить, но выясняется, что он был самописный, а связь с разработчиком потеряна. Что делать?

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

– Что и на каком этапе нужно сделать, чтобы сохранилась преемственность разработки? Чтобы можно было допилить даже, если сменились конкретные люди, писавшие код?

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

– Можно проводить такой аудит в процессе работы или только в самом конце? А то, знаете, это как заглядывать в черновики…

– Можно привлекать аудиторов, как только появляется первая работающая версия продукта. Главное — чтобы это не вставляло палки в колеса разработчику, чтобы не возникало конфликта.

– Третий пример из жизни: заказали сайт, получилось красиво, а конверсии – нет, пожертвования не пошли. На каком этапе нужно об этом думать, на какие метрики смотреть?

– Как говорится, ошибайся раньше, ошибайся чаще. Очень важно распланировать работу так, чтобы как можно раньше получить продукт, который можно показать пользователям. Это называется прототип. Прототипы бывают разные: даже нарисованный от руки набросок посадочной страницы сайта — уже прототип. Надо позвать человека из вашей целевой аудитории или кого-то, чье мнение для вас важно, показать этот набросок и получить обратную связь, Потом учесть ее и доработать.

Конечно, нужно выдержать баланс и чтобы это не очень тормозило разработку, но такие промежуточные точки, где мы показываем результат пользователям, должны быть обязательно. Тогда мы можем скорректировать направление движения. Не нужно большое исследование — можно показать трем-пяти пользователям и это будет в миллионы раз полезнее, чем выкатить полностью готовый продукт и обнаружить что все было не туда. Чем раньше вы будете показывать свой продукт, тем раньше вы ошибетесь, потому что ошибаются все, а если вы рано ошибетесь, то сможете не раннем этапе исправить ошибку.

– Еще один частый вопрос: как правильно составлять техническое задание (ТЗ)? Есть стандарты, шаблоны, рекомендации?

– Чего я точно советую избегать, так это ТЗ по ГОСТу (существует ГОСТ 34.602-89 от 01 января 1990 года и ГОСТ 19.001-77 от 01 января 1980 года – прим. автора). Вообще, информации об этом довольно много. Я об этом рассказывал в большой лекции для Яндекса, ее можно найти найти на youtube. В деталях она уже немного устарела, прошло почти пять лет, но общий посыл там все еще актуальный, особенно много полезного во второй части, где ответы на вопросы из зала. Плюс у нас в Гильдии была попытка создать «золотой стандарт» документации, где мы разрабатывали шаблоны в том числе для ТЗ.

«Как правильно поставить ТЗ на создание сайта», Школа вебмастеров

Четыре принципа Agile

– Что такое Agile? Объясните на пальцах.

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

Первый – люди и взаимодействия важнее, чем процессы и инструменты.

Второй – работающий продукт важнее, чем исчерпывающая документация.

Третий – сотрудничество с заказчиком важнее согласования условий контракта.

Четвертый – готовность к изменениям важнее следования первоначальному плану.

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

– Какая от всего этого практическая польза?

– Для заказчика плюс в том, что команда, работающая по agile-подходу, более гибкая, умеет адаптироваться под изменения и заинтересована в качественном продукте. Главный подводный камень – цена. Довольно сложно понять, какова будет стоимость работы, потому что высокая степень непредсказуемости и можно оценить только «вилку» суммы от и до, а заказчику же обычно хочется сразу понимать бюджет и сроки.

Фото Павла Смертина