Как контролировать разработку приложения

Денис Гордиенко, руководитель Bright Mobile, о том, как организовать работу с разработчиком при создании мобильных приложений на примере мессенджера.

Недавно мне позвонил один из подписчиков моего YouTube-канала с просьбой доделать приложение. Он заказывал некоторое время назад в одной из студий разработку мессенджера под iOS. Пока делалось приложение компания развалилась, все свои обязательства, насколько могли, выполнили, но не реализовали push-уведомления. Собственно, просьба звучала так, что нужно по исходникам разобраться в проекте и доработать push.

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

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

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

Разработчику виднее

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

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

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

Кто-то из разработчиков может так досконально не настаивать на проверке, а работать в формате "согласовал и ладно". Вообще, у многих разработчиков есть тенденция, все самое сложное оставлять на конец. В итоге, разработчик может сделать приложение процентов на 80, взять оплату только за сделанное и покинуть проект или расторгнуть договор. Например, как в случае выше, разработчик был уверен, что сделает push, но не смог. По закону всё чисто - деньги взяты пропорционально выполненной работе, но кому нужен мессенджер без моментальных уведомлений о новых сообщениях? Такой продукт не имеет потребительской ценности.

Версионный подход к разработке

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

Его понять можно. Обычно, у заказчика есть некий фиксированный бюджет, за рамки которого выходить не планирует. И ему важно, всё предусмотреть, чтобы весь перечень необходимых работ входил в выделенную сумму. Некоторые хотят сознательно сделать как можно больше функций в первой версии, рассчитывая, что такое приложение будет иметь больший спрос, кто-то считает, что "стрёмно" публиковать не доведённое до ума, с его точки зрения приложение.

Но чем больше задача, тем меньше шансов дойти до финала. Потому что прочность цепи равна прочности самого слабого звена. Чем больше звеньев - тем больше шанс понизить прочность. Применяя к разработке это выглядит так. На каком-то из модулей (push-уведомления) программист что-то не учёл, при этом оставив его на потом. В итоге приложение посыпалось.

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

Рассмотрим на примере мессенджера. На какие версии можно разделить разработку?

Минимальный мессенджер состоит из следующих экранов:

  1. Регистрация/Авторизация
  2. Список контактов
  3. Переписка
  4. Создание общего чата
  5. Просмотр профиля
  6. Редактирование своего профиля
  7. Настройки
  8. Меню
  9. Пользовательское соглашение
  10. Уведомления

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

Но даже из 10 функций выше можно выделить несколько, которые нужно сделать в самом начале разработки, чтобы понять, что разработчик справится с задачей. Эта микроверсия будет содержать:

  1. Регистрация/Авторизация
  2. Список контактов
  3. Переписка
  4. Уведомления

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

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

Спокойствие в выпуске версий

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

По опыту могу привести принципиальные функциональные элементы ещё для нескольких видов проектов.

Маркетплейс услуг. Общая логика - заказчик размещает заказ, по какому-то принципу назначается или выбирается исполнитель, сервис зарабатывает комиссию.

  1. Регистрация/Авторизация
  2. Создание заявки
  3. Просмотр и отклик, либо функционал автоназначения исполнителя
  4. Контактные блоки заказчика с исполнителем (переписка, телефон или иное, что закладывается в проект)
  5. Уведомления
  6. Функционал монетизации

Товарный маркетплейс. Сторонние вендоры размещают свои товары, они агрегируются на площадке, кленты заказывают товары, продавцы уведомляются о заказах, площадка зарабатывает комиссию.

  1. Регистрация/Авторизация
  2. Загрузка номенклатуры поставщика
  3. Витрина с предложениями
  4. Возможность заказа (не обязательно покупка, можно просто оформление заказа или контакты продавца)
  5. Уведомления
  6. Функционал монетизации

Доска объявлений. Одни пользователи размещают объявления, другие связываются с авторами объявлений, площадка зарабатывает на доп. услугах.

  1. Регистрация/Авторизация
  2. Размещение объявления
  3. Лента объявлений
  4. Возможность контакта (переписка, телефон или иное, что закладывается в проект)
  5. Уведомления
  6. Функционал монетизации

По ходу статьи я использовал слова "программист" и "разработчик". Они подразумевают, как работу с программистом в штате или на фрилансе, так и со студиями.

0
67 комментариев
Написать комментарий...
Руслан Семагин

Блин, читая очередной опус, не перестаю удивляться. 

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

Вы регулярно несёте какую-то дичь вроде из разряда «программист в штате это дорого и опасно», «пуш уведомления это люто сложно и мало кто это умеет готовить», «мы делаем приложения которые держат 100 миллионов чего-то там» и т.д., и т.п.

И те кто это читают, кто не в теме, наверняка затаив дыхание думают «блин, а кругом то одни сложности и враги», «ого, 100млн! Вот это ребята монстры, наверное изобрели нечто такое что никому не подвластно и сложно»…. и,…. Несут деньги в кассу.
А по прошествии времени - рыдают над не сбывшимся. И коллективно обсуждают в чате в вотсапе как остались ни с чем.

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

Когда у клиентов начинаются неудобные вопросы - контакты прекращаются. 

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

Один из таких не технических моментов - это 152 ФЗ, и в частности его ст.12 - Трансграничная передача персональных данных.

Речь о том, что вы втираете клиентам про Firebase, про сто миллионов чего-то там - они ведутся.
Но проблема в том, что вы всё тупо храните там, потому что это очень просто, примитивно и дёшево в реализации.
Но почему ваши клиенты не получают от вас информацию по 12 статье 152ФЗ?

http://www.consultant.ru/document/cons_doc_LAW_61801/e4ebbe1780de623c7cf32a59ca82a7bb523a25dd/

Или инфраструктура Firebase переехала куда-то под Волгоград или в Химки чтобы можно было это использовать в качестве основного и по сути единственного хранилища ПД?

Я напомню, что c некоторого времени, даже отдельно взятый email является персональными данными - https://www.garant.ru/products/ipo/prime/doc/71879312/

Вы же, тупо храните там всё. Вы об этом знаете - клиент скорее нет.

На трансграничную передачу ПД требуется письменное (то, которое на бумаге) согласие конкретного лица. Оферта это не закрывает.

Про санкции найдёте по ссылке выше. Все сомнения можете развеять посредством письменного запроса в Роскомнадзор.

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

Имею с десяток контактов таких, кто когда-то повёлся.

Работа по принципу «без лоха и жизнь плоха» не красит человека.

Ответить
Развернуть ветку
Денис Гордиенко
Автор

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

Сервера Firebase находятся в США. Закон, в т.ч. сбор письменных согласий, распространяется на конкретный список стран, куда США не входит. Цитата ". Уполномоченный орган по защите прав субъектов персональных данных утверждает перечень иностранных государств, не являющихся сторонами Конвенции Совета Европы о защите физических лиц при автоматизированной обработке персональных данных и обеспечивающих адекватную защиту прав субъектов персональных данных. Государство, не являющееся стороной Конвенции Совета Европы о защите физических лиц при автоматизированной обработке персональных данных, может быть включено в перечень иностранных государств, обеспечивающих адекватную защиту прав субъектов персональных данных, при условии соответствия положениям указанной Конвенции действующих в соответствующем государстве норм права и применяемых мер безопасности персональных данных."

Собственно, сам блек лист стран, где нужно письменное подтверждение - http://www.consultant.ru/document/cons_doc_LAW_145512/512d64e9cf5315c1dfc19401938763a3afcab2f8/#dst100012

Но вы и дальше можете баламутить людей в каком-то чатике вотсапа. За год работы с Firebase ни один клиент не пришёл с подобной проблемой. 

Ответить
Развернуть ветку
Руслан Семагин

Ещё раз, перестаньте засирать людям мозг про миллионы и миллиарды.
Ещё раз, внимательно перечитайте ФЗ.
Если недостачно веществ для толкования, это не обязательно, достаточно сделать запрос в Роскомнадзор.
Воспользуйтесь при случае.

Читайте как про хранение, так и про трансграничную передачу данных.

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

Трансграничка это один момент, второй - хранение на территории РФ.

В вашем случае, это и первое и второе.

Денис, не позорьтесь. Сделайте запрос, получите ответ, и "работайте" сколько душе угодно.

"За год работы никто не пришёл..." - это конечно железный аргумент.
Не пришел клиент потому что он может и не знать, т.к. вы ему не сказали.
Но когда придут к нему (с это вероятно вполне) - вы умоете руки, дёрнете за верёвку и сольётесь.

И это только то, что на поверхности, и доступно любому желающему.

Что там под капотом, это отдельная история.

Ответить
Развернуть ветку
Руслан Семагин

Посмотрел свежий видео-опус https://www.youtube.com/watch?v=24Cs8MBDeMk, в котором разбирается кейс какого-то проекта, который как говорит автор «скоро будем релизить». 

Ок, проект как проект, детали никому не интересны. 

Интересует другое, вот видим у проекта есть владелец, юридическое лицо ООО «Аква-С». 

Есть даже оферта и политика обработки ПД которая ссылается на ФЗ 152. Это хорошо. 

Соответственно, вы вероятно заключили договор на оказание услуг и т.д. 

Просто как пример, вот конкретно это ООО (если данные не рыба конечно) в лице генерального директора Бурцева Константина Вячеславовича (опять если таки не рыба) в курсе что у них более чем полный пакет ПД хранится, обрабатывается, систематизируется, редактируется, уничтожается и т.д., на территории иностранного государства? 

Тут без привязки хорошо это или плохо, без учёта нравится/не нравится, просто и тупо - в курсе или нет? 

Т.е. Вы предложили клиенту некий стек, разъяснили-ли вы что и как?

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

https://www.garant.ru/actual/persona/otvetstvennost/

Каждый случай - это один факт. 

Допустим, 100 фактов (флешмоб по сути), к примеру для юридического лица, пусть в среднем будет минус 3 миллиона рублей. 

Так давайте спросим у Бурцева Константина Вячеславовича, как оно, всё ок? 

Так сколько вы говорите можно сэкономить купив/заказав ваши поделки и погремушки, «потестировав идею на малых суммах»? 

Опять таки, рекомендую получить официальную позицию ведомства по этому вопросу. 

Да даже не нужно что-то писать, любому желающему доступен такой инструмент как телефон РКН, где по телефону прямо и формулирую эту самую позицию. 

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

Таким образом, в случае если позиция ведомства будет такова что то что предлагается и практически реализуется клиентам на коммерческой основе не соответствует данному ФЗ, то вся и без того почти нулевая стоимость и ценность данной поделки для проекта из РФ - сводится к нулю. 

Ещё раз, конечно и безусловно, вообще не нужно как-то особо доверять моему комментарию. Нужно просто любому желающему взять трубку и позвонить в филиал РКН в своём городе, или написать запрос через форму на сайте. 

Описав в сути запроса инфраструктуру проекта, перечень операций с данными, средства и каналы доставки данных, и хранилище. И получить ответ. 

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

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Я то всё думаю, чего вы говнитесь так. А тут ребята скинули - https://marketplace.1c-bitrix.ru/solutions/democontent2.pi

Конкуренция, понимаю...

Ответить
Развернуть ветку
Руслан Семагин

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

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

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

Но т.к. вы Денис, какбы съезжаете с темы, ок, мне не трудно, запрошу сам.

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Видео удалено по просьбе клиента до момента релиза. Ваша бредятина, где вы путаете понятия обработки, хранения и не учитываете список стран к этому отношения не имеет. Приходите через пару неделек, статья будет.
А вы перед запросом прочитайте всё-таки закон, а то перед РКН неудобно будет.

Ответить
Развернуть ветку
Руслан Семагин

Да нет, почему же.
Всё удобно. Я прочитал, прочитал не раз. И более того, инфа то как раз по случаю пришла на этой неделе, и подтверждена как раз на приёме в РКН. Вот и про вас вспомнил и пришёл написать.
Поэтому, если филиал филиалу не противоречит, осталось получить бумажку.

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Как будет, присылайте, там и поговорим

Ответить
Развернуть ветку
Руслан Семагин

Пришёл ответ от Роскомнадзора. Трансграничка есть, письменное согласие не надо, оферту о трансграничке - можно. 

Сбор, обновление, изменение за пределами РФ - нельзя.

А теперь, Денис, напишите пожалуйста адрес где расположен ДЦ FireBase.

Ответить
Развернуть ветку
Руслан Семагин

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

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Ага, заодно Рыжикову скиньте, а то он с дуру свой saas на немецких серверах Амазона хранит и обрабатывает. 

Ответить
Развернуть ветку
Руслан Семагин

Денис, избавьтесь от этой дурной привычки переводить стрелки и съезжать с темы. 

Как дитя малое (а Петька тоже виноват, что только я то!).

Отвечайте за себя. Услуги ваши, вопрос был задан вам.

Да, он не удобный, но он есть.
Мы с вами решили, что каким бы ни был ответ, он будет опубликован тут, в этой ветке комментариев.

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

Ответить
Развернуть ветку
Руслан Семагин

Итак, чтобы не было словоблудия и пустословия, а также чтобы вам не удалось как вы привыкли съехать с темы. Как и обещал, мною направлено обращение в РНК. 

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

Ответить
Развернуть ветку
Виталий Подольский

Боже, по моему, это последний гвоздь в крышку гроба 😂

Ответить
Развернуть ветку
Руслан Семагин

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

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

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

Ответить
Развернуть ветку
Виталий Подольский

У меня сегодня ученик интересное слово придумал. Он говорил девелопер, но прозвучало как "дибилопер", очень в тему, как мне кажется 😂

Ответить
Развернуть ветку
64 комментария
Раскрывать всегда