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

Денис Гордиенко, руководитель 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. Функционал монетизации

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

Материал опубликован пользователем.
Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Денис Гордиенко", "author_type": "self", "tags": [], "comments": 65, "likes": 16, "favorites": 198, "is_advertisement": false, "subsite_label": "life", "id": 94868, "is_wide": false, "is_ugc": true, "date": "Sat, 30 Nov 2019 17:29:49 +0300", "is_special": false }
0
{ "id": 94868, "author_id": 127886, "diff_limit": 1000, "urls": {"diff":"\/comments\/94868\/get","add":"\/comments\/94868\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/94868"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199123, "last_count_and_date": null }
65 комментариев
Популярные
По порядку
Написать комментарий...
3

"разработчик был уверен, что сделает push, но не смог" - звучит странно, это чуть ли не самое простое что можно сделать

Ответить
1

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

Ответить
1

Про webview не спорю, но я не про webview, а про нативщину ) В приложениях на webview, react native и прочем погибнуть можно практически на всем.

Ответить
0

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

Ответить
1

Это странно только в том случае, если приложение делал профессионал. Тут похоже выходец с курсов решил поработать на портфолио =)

Ответить
3

Как пасти котов? Очень просто - коты в основном бывают трёх типов. Главное в коте - усы, лапы и хвост.
А так - портфолио не айс, а об мобильную версию сайта глаза сломал.

Ответить

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

2

 разобраться в проекте и доработать push

Эк все печально у вас. Это всего несколько строк кода =) погли и заработать немного

Ответить
0

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

Ответить
4

Да ладно, не интересно! Свои люди, можем не лукавить =) Мой средний доход с разработки более 300к в месяц, почему бы мне не заработать еще 8-10 за плевый функционал? Если начать нос воротить, то можно и не заметить, как спрос на конкретного разработчика сошел на нет! А тольятинская молодая студия с бедным портфолио должна рыть копытом землю! 

Я же стараюсь: основная работа + пет-проекты + разовый фриланс + платное менторство = профит. У вас же приложение из портфолио стоит меньше =). А вы говорите, не интересно.

Ответить
1

Я же стараюсь: основная работа + пет-проекты + разовый фриланс + платное менторство = профит.

а жить когда? =)

Ответить
1

Так это и есть жизнь! Главное, чтобы было чувство удовлетворения. Ну и как захочешь, можно отдохнуть, никто же не мешает

Ответить
0

Хороший комментарий, дал тему для отдельной статьи.

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

1. 8-10к за плёвый функционал - хорошие деньги. Если хотите - дам контакты клиента. Сам не беру, т.к. администрирование этой задачи не сопостовимо с прибылью.

2. Боязнь потерять заказы. Как правило отвлечение на микрозадачи и даёт предел в заработке. 300к вполне неплохо для личного дохода фрилансера, но мне такая прибыль, а уж тем более оборот не интересны. Само собой, что сначала формируется очередь заказов, а далее выбираешь наиболее интересные, а не наоборот

3. Что и кому должна молодая студия с бедным портфолио решать её руководителю.

4. Вы почему-то свой ежемесячный доход сравниваете со стоимостью самого дешевого проекта в портфолио. В чём прикол? Ну, ок, у нас среднемесячный оборот 1-1,3 млн, дальше то что? Фишка же не в стоимости проекта, а в прибыли. Конкретно тот проект, который вы скинули по трудозатратам занимает 16 часов работы ПМа на нашем прошлом ядре Сервис ПИ. Это значит, что проект запускается за неделю и чистой прибыли в нём 182к

5. Вы молодец, что стараетесь. Это социально положительное занятие. Я же стараюсь стараться в бизнесе в тех делах, которые выгодны, а прочие передаю коллегам или партнёрам.

Ответить
3

 Боязнь потерять заказы.

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

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

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

P.S. Ничего личного, мои наблюдения, основанные на опыте!

Ответить
1

 Можно вопрос не по теме.
Ваш сайт? https://devlab.studio/
А зачем у Вас пол текста на русском, пол на английском?
Тут либо все на русском, либо все на английском, либо переключатель языка вверху справа.

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

 Плюс, что это за кнопка LogIn и Try for Free и помесячные цены?
У Вас дизайн студия или сервис?
Вызывает недоумение... Как будто все в кучу сгребли.

Ответить
0

Можно. Сайт не доделан. Я даже не решил до конца, нужен ли он мне вообще =) Основное предназначение, использование разного апи на поддоменах. Вебморду начал делать, но пока нет времени ее закончить =) Плевать, одним словом!

Ответить
0

Скажите пожалуйста, как вы находите клиентов на платное менторство? 

Ответить
0

Все просто. Я преподаю язык два раза в неделю. Отсюда и менторство происходит.

Ответить
0

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

Ответить
0

Попробуйте на фл разместить заявку на доработку нативного ios приложения и увидите ответ

Ответить
3

ФЛ? ну если говорить про фриланс, то только upwork, наши биржи еще те помойки. Я там и размещать не буду. Нервы дороже!

Ответить
1

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

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

Вы регулярно несёте какую-то дичь вроде из разряда «программист в штате это дорого и опасно», «пуш уведомления это люто сложно и мало кто это умеет готовить», «мы делаем приложения которые держат 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/

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

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

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

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

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

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

Ответить
1

Все четко расписали. Я даже заранее поржал с будущих ответов гуру бизнес-разработки 😂👍🏼

Ответить
0

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

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

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

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

Ответить
1

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

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

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

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

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

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

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

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

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

Ответить
1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответить
0

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

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

Ответить
1

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

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

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

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

Ответить
0

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

Ответить
1

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

Ответить
0

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

Ответить
1

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

Ответить
0

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

Ответить
1

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

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

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

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

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

Ответить
1

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

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

Ответить
0

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

Ответить
1

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

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

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

Ответить
0

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

Ответить
1

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

Ответить
0

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

https://xsfera.ru/2019/11/изучил-react-native/

Ответить
0

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

Ответить
0

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

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

Ответить
2

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

Ответить
0

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

Ответить
1

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

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

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

Какой еще самопис?! Или вы про нейтив говорите? Или про самопи..ец? =) 

Вот тут вы в корне не правы, нейтив проще отладить/доделать/рефакторить, чем кроссплатформу с тонной сторонних библиотек.

Что то мне подсказывает, что ваши 9 лет руководства программерами сильно ограничены удаленностью региона. Вы не развиваетесь, а поймали одну волну и гоните ее дальше, как единственно правильную. Может пора расширить кругозор? Я понимаю, что для местечкового бизнеса лучше и дешевле заказывать подобные приложения, чем каждому нейтиву более 200к в месяц платить.

Ответить
1

Программист хочет держать всё под контролем почему-то считая, что сторонние модули писали люди глупее, чем он

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

Ответить
0

Назовите хоть пару принципиальных для бизнес-приложения

Ответить
0

Может стоит начать с того, что вы подразумеваете под бизнес-приложениями? =)

Ответить
0

Примеры направлений в статье

Ответить
1

Ну это поделки, на серьезный бизнес не тянут. Хотя, если заказчику все равно как работает его приложение, тогда норм. Бизнес, это когда продуманный дизайн, UX/UI. Когда интерфейс анимирован, не жрется батарейка без особых причин. Когда все плавно и стабильно, новая фича планируется и реализуется без нервных судорог разработчика. Когда можно кастомные контролы делать. Когда тесты есть, юнит, интеграционные, приемочные и прочее. А фризы и вес приложения из разряда, чтобы было =)

Ответить
0

А если с переходами, то может и неделя уйти. Пуши это не мелочь и работать надо в паре с backend dev'ом зачастую. Никогда не понимал, почему в ТЗ и брифах одной строкой в конце упоминают.

Ответить
0

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

Ответить
0

А дизайн - это не про mvp. «Малые суммы» - это не когда разработчик за дошик работает, а когда выделяется очень маленький функционал чисто для проверки и из-за объема он стоит мало. 

и да, на малых суммах это за 200-300к за первую версию. 

Ответить
0

по сути 200-300к за ранее написанный кому-то шаблон?

Ответить
3

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

Есть такая поговорка, на словах он Лев Толстой,  а на деле х... простой. Человека жалко. Копит деньги на проект, верит, что сможет реализовать свою мечту, но находит такого пафосного ушлепка и отдает ему свои сбережения. В итоге, на выходе ничего. И тут он что то рассказывает за свои обороты, какой он эффективный в бизнесе и как спасает мир со своим иоником. 

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

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

Ответить
2

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

1. кивают на прошлые "заслуги"
2. зашкварно накидывают ботов, заряженных восторгом
3. их больше волнует кто говорит, чем о чем говорят
4. их волнуют только бабки, а не работа, потому, вообще не стремятся к общению

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

Ответить
0

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

Ответить
1

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

Ответить
0

Да все можно решить, если исполнителя искать неспешно. Лучше того, с кем ранее кто то из знакомых работал и может поручиться за него. А тут с самого начала понятно, что тип мутный и тупо трафик пробует себе лить. Но зато слова умные пробует писать 😂

Ответить
1

а мне такие мутные нравятся: есть на ком чуйку тестить

Ответить
1

смог оценить масштаб катастрофы 

Виталий, имейте совесть, всё-таки словоблудие и написание говно-кода - это разные профессии. :) 

Нельзя так вот валить и переоценивать возможности одного человека.
В комплекте есть чувак, который ранее сам себя именовал «Senior Mobile Developer», а сейчас именует не иначе как «Full Stack Developer» и «Senior Developer». 

Тут слаженный тандем.

Ответить
0

Я долго думал, у меня перед глазами говнокод или катастрофа? Остановился на последнем 😂 Говнокод хоть криво, но работает!

Ответить
0

жизнь вообще полна сюрпризов

Ответить
0

Причём тут ранее кому-то написанный шаблон?

Ответить
0

Похоже Дениска даже тут увидели твою суть...

Ответить

Комментарий удален

0

Ну да, да: "пилите сначала MVP" - сколько раз уже твердили.

Ответить
{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "Article Branding", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "cfovx", "p2": "glug" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Баннер в ленте на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "disable": true, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } }, { "id": 20, "label": "Кнопка в сайдбаре", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "cgxmr", "p2": "gnwc" } } } ] { "page_type": "default" }