Статья нацелена в первую очередь на новичков, желающих сделать свое первое мобильное приложение, и, как мы в свое время, абсолютно не знающих с чего начать и присматривающихся к недорогим вариантам программирования. Отчасти в некоторых местах она будет интересна и мастодонтам мобайла в качестве интересного примера для борьбы с возражениями будущих не ретивых клиентов.
Вводная часть
На волне подъема развлекательных мобильных приложений и вирусных видео о разнообразных челленджах, у вашего покорного слуги родилась идея создать развлекательное мобильное приложение с тематикой челленджей и флешмобов. Забегая вперед скажу, что несмотря на описанные ниже ужасы, нам все такие удалось реализовать проект и выпустить в сторы beta-версию для iOS и полноценную версию для Android.
Для данной публикации достаточно будет сказать, что за реализацию идеи мы с командой идеологов взялись без малейшего набора знания в мобильной разработке, рекламе и всех сопутствующих тонкостях отрасли.
Собственные кейсы и лайфхаки
Ниже я опишу сухие цифры, примеры собственных кейсов, советы и топ лайфхаков по выбору программистов. На мой скромный взгляд это должны знать все, кто очень хочет сделать свое первое мобильное приложение, но не знает с чего начать. Скорее всего, некоторые советы подойдут в поиске исполнителей и в других областях и сферах.
1. При поиске подрядчика (в нашем случае — разработчика) не занимайтесь поиском его в Гугле или Яндексе. Найдите ТОП мобильных разработчиков за 2 года и идите по данному списку. Конечно, это не даст 100% гарантии, что вы найдете грамотного, ответственного и порядочного партнера (об этом чуть позже), но это даст гарантию того, что разработчики действительно имеют опыт в разработке мобильных приложений, а не «во всем понемногу».
Пример из жизни: при реализации проекта мы два раза прибегали к поиску программистов через обычные поисковые сервисы и составляли списки потенциальных разработчиков. Через два года, когда пришло понимание того, как нужно выбирать программистов, мы сравнивали наши прошлые списки с полученными позже инсайдами и отзывами от коллег по отрасли. С большей частью разработчиков из этого списка или, мягко говоря, работать не рекомендовали, или их обещания на деле могли разойтись с реальными возможностями. При этом ни одна из ТОП 50 компаний-разработчиков России в список, составленные по результатам поиска через Гугл и Яндекс не попала.
2. При составлении шорт-листа компаний, с которыми потенциально можно работать, обращайте внимание на реализованные проекты и не стесняйтесь звонить их клиентам из портфолио. Довольные клиенты с удовольствием расскажут и рекомендуют данного партнера, а недовольные с еще большим удовольствием отговорят заключать с ним контракт.
Пример из жизни: мы вели переговоры с компанией, которая снимает в офис в очень дорогом БЦ в Москве и имеет цены далеко выше среднего. Казалось бы, это должно было говорить о высоком профессионализме и наличие большого числа серьезных клиентов.
Впоследствии нам удалось получить инсайд от работников этой компании. Выяснилось, что экспертиза в мобайле у данной компании невысокая, в отличие от web-разработки, что не мешало сделать нам предложение с высокой ценой и обещанием реализовать любые вещи. Проект реализовать было можно, но это, скорее всего, была бы не та конфетка, которую бы мы хотели получить за те высокие цены, которые предлагались.
3. При выборе подрядчика обязательно обращайте внимание на реализованные им проекты. Идеально, если подрядчик реализовывал или похожее приложение, или уже реализовывал части вашего предполагаемого функционала в других приложениях. Пройдитесь по общему функционалу и по отдельным функциям приложениям. Попросите показать живые, реализованные примеры похожих работ и функций. При этом желательно, чтобы это был не один проект, на котором могла происходить проба пера.
Если функционал вашего приложения похож на «социалочку», а разработчики, менеджеры проекта и директора говорят вам, что они сами не пользуются социальными сетями, но бьют себя в грудь и заявляют, что легко реализуют ваш проект – смело уходите со встречи. Скорее всего, у них будет крайне низкая экспертиза именно в вашем вопросе, и проект будет реализован криво.
Немало важно, были ли показанные вам примеры проектов выпущены в стор и поддерживают ли они их в данный момент. Если приложения не были выпущены или выпущены, но кардинально отличаются от того, что показывает вам потенциальный партнер – это первый серьезный звонок.
Пример из жизни: наш менеджер проекта и директор поверхностно знали функционал всех социальных сетей и вещи, которые на наш взгляд являлись нерушимыми и само собой разумеющимися, оказались или нереализованными, или на их взгляд тяжело реализуемыми. Серверный программист не имел до этого опыта работы с мобильными приложениями, и допустил такие ошибки, которые в итоге с неимоверным набором багов решались только полным переписыванием серверной части.
4. Если рассматриваемый вами партнер не придерживается этики ведения переговоров и не отличается пунктуальностью, не тратьте на него время. Как клиент вы ему не интересны и работа с ним, скорее всего, продолжится в непунктуальном ключе. У вас будут постоянные проблемы с работой, контролем, сроками и отношением к проекту в целом.
Пример из жизни: после того, как у нас остро встал вопрос о смене подрядчика, начались переговоры с рядом компаний из ТОПа разработчиков России. Удивительно было то, как на первоначальном этапе ряд компаний пренебрежительно относились к нам, как к клиенту.
Сразу оговорюсь, что мы были готовы принять условие оплаты код-ревью, приехать в другой город на переговоры и предоставить исходные коды приложения. Блин, да мы были практически идеальным клиентом.
Некоторые из таких компаний умудрялись забывать перезвонить в назначенный срок, вспоминать о нашем письме через неделю или вообще забывали о факте наших переговоров.
Интересная история случилась с одной Питерской компанией. У нас была готова версия под iOS, и нам нужно было сделать точную по функционалу копию приложения для Android. Мы предложили выслать описание нашего проекта, дать доступ к iOS-сборке и приехать на встречу, на что получили ответ: «Мы так посчитаем, по описанию, нам смотреть работающее приложение не обязательно». При этом портфолио компании пестрило большими и серьезными проектами. В итоге, прошу заметить, переговоры с ними ничем так и не закончились, спустя год я так и жду от них письма или хотя бы звонка с коммерческим предложением.
5. Спрашивайте мнение у экспертов из отрасли. Было приятно убедиться несколько раз на собственном опыте, что профессиональное комьюнити достаточно тепло и активно помогает нуждающимся в совете людям. Ищите профильные группы в Facebook, не стесняйтесь задавать вопросы о конкретных компаниях, с которыми хотите работать, просите совета, в тех или иных областях. В больше части найдется куча полезных советов и приятных людей, которые готовы подсказать и помочь.
Что бывает, если не следовать этим рекомендациям
Итог работы объективно
- Срыв сроков в 2 раза;
- Колоссальные операционные расходы, которые мы понесли из-за срыва сроков сдачи проекта и дебаг;
- Исправление багов по принципу «когда у программистов будет время»;
- Нереализованные функции и неисправленные баги. В один из моментов у нашего партнера просто закончились деньги, чтобы платить зарплату своим программистам. В итоге нам сдали частично незаконченную работу с кучей явных багов;
Итог работы после независимого код-ревью
- Неправильно реализованные основополагающие функции и методы – отсутствие кеширования, неправильные методы авторизации пользователей, отсутствие безопасности, как класса. Много мелких багов средней критичности и проблем, которые обязательно возникнут на определенных стадиях развития проекта, и которые снимаются только полным переписыванием кода серверной части;
- Полное отсутствие безопасности. Приложение ломалось любым пользователем с начальными знаниями HTML и простым кодом на 300 символов, по сути, являющимся таблицей, куда вводятся нужные данные;
- Гигантское число багов с трудно вычислимыми причинами. Код был написан аккуратно, но с зачастую полным отсутствием здравого смысла в написанной функции или принципе исправления какого-либо бага. В некоторых случаях приходилось просто переписывать полностью куски кода или части функционала;
- Спустя месяц главная страница приложения загружалась минуту. На лицо был программинг «на костылях», когда функция работает и слава Богу, но лучше «там» ничего не трогать;
Итоги работы в деньгах
Исправление багов и самых критичных вещей вышли по стоимости на уровень написания новой серверной части в компании, которая действительно имеет опыт мобильной разработки.
Программирование у неопытных и дешевых программистов, операционные расходы на время программирования, операционные расходы из-за срыва сроков, стоимость исправление багов у новых программистов, операционные расходы на время исправления багов = стоимость серверной и клиентской части под одну платформу с более широким функционалом у компании из ТОП-30 разработчиков России.
Заключение
Новыми программистами проект был оценен уже как средний по сложности и большая часть функций из разряда «сложно, мы умоемся кровью, когда будем их реализовывать» перекочевала в разряд «мы это делали четыре раза в других проектах, сделаем и у вас, в этом нет ничего сложного».
Кстати, та самая компания, которая так «хорошо» реализовала нам проект, переехала по счастливому стечению обстоятельств в «Москва-Сити», что подтверждает теорию о том, что высокие цены и пафосный офис далеко не всегда являются залогом высокого профессионализма.
Встречайте по одежке, провожайте по уму и не будьте дураками, учитесь на чужих ошибках (например, наших), а не на своих.
Комментарии (43)
Terras
15.11.2016 13:56+9Кстати, та самая компания, которая так «хорошо» реализовала нам проект, переехала по счастливому стечению обстоятельств в «Москва-Сити», что подтверждает теорию о том, что высокие цены и пафосный офис далеко не всегда являются залогом высокого профессионализма.
Петя потратил выручку на новый дорогой офис в «Москва-Сити», а Вася потратил выручку на новых разработчиков/новую аппаратуру/лицензии/запуск нового продукта. В итоге, Петя подтверждает теорию Bammbato, а Вася получает развитие.
Coffin
15.11.2016 14:14+5Итог работы после независимого код-ревью
А в тз обо всем этом говорилось?
А то как бы писать о том чего нет, если вы этого не запрашивал — не хорошо.Bammbato
15.11.2016 16:21-4Итог работы после независимого код-ревью
А в тз обо всем этом говорилось?
А то как бы писать о том чего нет, если вы этого не запрашивал — не хорошо.
Понадеялись, что какие-то вещи являются само собой разумеющимися, и из-за отсутствия какого-либо опыта в этой области оставили их на совесть разработчика, сами дураки. Да, какие-то вещи описывались, какие-то проговаривались устно, какие-то не описывались.
Проблема в том, что мы считали, что какие-то вещи, которые должны быть де-факто у каждого проекта.
Например, загрузка главной страницы не должна из 1 секунды превращаться в минуту через месяц после запуска проекта. Да, можно говорить об отсутствии кеширования в ТЗ, как и можно говорить об отсутствии здравого смысла не делать его, при прогнозировании данной проблемы в такие короткие сроки.
Забегая вперед скажу, что с нынешними разработчиками работа строилась уже с бОльшим пониманием процессов на основании старых косяков, хотя во многом старались доверять их профессионализму. Закрыли кучу потенциальных проблем, о которых мы не знали, не смогли бы спрогнозировать, и уж тем более описать в ТЗ. Тут вопрос, конечно, все равно к скиллам, опыту и порядочности команды разработчиков.Coffin
15.11.2016 16:30+5Но тут все дело в том, что какие-то базовые вещи — понятие очень растяжимое, как вы понимаете.
Если включить все в «базовые вещи» и когда вам покажут ценник в 10 рублей, то вы скажете, а че так дорого?
Вон у Васи и Ко, за 2 рубля :)
Кеширование — разное бывает, стоимость его разработки будет тоже разная в зависимости от…
Загрузка страницы за 1 сек тоже может быть «багом» или еще чем, может быть с сервером связано или еще с чем, так что тут тоже все относительно.
т.е. заказывая разработку, вы должны понимать, что потом должна быть поддержка т.к. никто никогда не напишет вам ничего, что не надо исправлять и «допиливать».
Тоже можно сказать и про безопасность, есть конечно какие-то базовые принципы вроде не хранения паролей в открытом виде, но если в ТЗ это не написано, то тогда кто как хочет тот так и делает.
Поэтому как сказал https://habrahabr.ru/post/315332/#comment_9911030, если ему говорят сделай копию, то он хочет ТЗ, ведь у всех разное понимание копий :)Bammbato
15.11.2016 17:03+2Но тут все дело в том, что какие-то базовые вещи — понятие очень растяжимое, как вы понимаете.
Если включить все в «базовые вещи» и когда вам покажут ценник в 10 рублей, то вы скажете, а че так дорого?
Вон у Васи и Ко, за 2 рубля :)
Согласен, но опять же тут вопрос и нашей неопытности.
Кеширование — разное бывает, стоимость его разработки будет тоже разная в зависимости от…
Загрузка страницы за 1 сек тоже может быть «багом» или еще чем, может быть с сервером связано или еще с чем, так что тут тоже все относительно.
Сервер работает как часы *сплевывает 3 раза через плече*. Проблему исправили, больше она не возникала.
т.е. заказывая разработку, вы должны понимать, что потом должна быть поддержка т.к. никто никогда не напишет вам ничего, что не надо исправлять и «допиливать».
С возникающими проблемами согласен, те же пользовательские сценарии сколько не гоняй, все равно что-то, да вылезет. Но есть вещи, которые прогнозируются уже на этапе составления архитектуры — нагрузки, объем контента, количество запросов. Если в ТЗ написано, что проект должен держать одновременно 100.000 пользователей, то странно, что все сдувается на отметке 1000 :)
yara_73
16.11.2016 03:34Извините, за глупый вопрос: а как вы следили за написанием продукта для вас? Вот строите вы дом и хотите что бы там бегало свободно 10 детей, вы перед тем как подписать акт сдачи дадите им пробежать хотя бы по размеченной колышками земле что бы понять насколько это реально и будете это проверять при каждой возможности. Ваш подрядчик хочет получить больше денег затратив меньше ресурсов, как и вы тогда почему вы удивляетесь, что они плохо тестируют, не им этим пользоваться — это нужно вам в первую очередь. Опять же сугубо личное мнение.
Al-Vas
16.11.2016 05:11Хороший исполнитель должен предполагать что заказчик дурак и сам сказать как делать правильно, а не красиво.
Debug_all
16.11.2016 13:30Проводя автомобильные аналогии, Вы заказали разработку абстрактной машины с четырьмя колесами, крышей и рулем, на выходе получили два сваренных друг с другом велосипеда с запряженной костылями лошадью и прикрученным синей изолентой пляжным зонтиком (или Лада Калину). После чего удивляетесь, что у нее нет адаптивных систем безопасности, круиз-контроля, разгона до 100 за 3 секунды и шильдика S63 AMG — 21й век на дворе ведь, это само собой разумеющиеся вещи.
Bammbato
16.11.2016 13:33Ну, мы не на столько наглые заказчики. АКП, 4 сидения и сигнализация было бы вполне достаточно.
taujavarob
16.11.2016 17:18>Ну, мы не на столько наглые заказчики. АКП, 4 сидения и сигнализация было бы вполне достаточно.
Заказчик может придраться к чему угодно.
— Я недавно смотрел авто, всё на месте и «АКП, 4 сидения и сигнализация» — но кнопочки какие то такие уродливые и из такого пластика что просто… плакать хочется — и это в 21 веке то!?
P.S. То что у авто в 2016 году задние тормоза — барабанные — это уже, ладно, типа фича.
P.P.S. Недавно выбирал холодильник… Самсунг. Рядом стояли российской сборки и настоящий -из Кореи (в 1.5 раза дороже) — да, там тот же компрессор- но пластмасса фурнитуры настоящего корейца (на дверце которая) в два раза толще!!!
Эх. Аналогии.
smple
15.11.2016 17:04+3к сожалению работал с подобными исполнителями
этого нет в тз, как можно в тз написать что приложение должно быть безопасным? не должно быть sql injection или xss, как это проверить? откуда заказчик должен знать о существование sql injection и xss? если он знает что это такое и как проверить, возможно ему уже не требуется разработка?Bammbato
15.11.2016 17:07+1Совершенно верно. Не всегда заказчик и исполнитель общаются на одном языке.
Lofer
15.11.2016 22:57+4К сожалению работал с такими Заказчиками. :)
— Хотим вот Такую Крутую Штуку.
— Ок. Можем сделать. 1 000 денег.
— Не! Ребята, вы офигели. Те Парни такое делают за 200 денег!
— Но мы вам сразу сделаем и защиту от sql injection, xss, и шифрование и прочее. Да еще и тестирование на 10 Осях и 20 устройствах. Сразу в пакете.
— Не парни, вы нас на бабки разводите! А вот еще Лучший Приятель, сказал что розовые единороги пасутся на радуге! Пошли нафиг Злые Программеры!!!smple
15.11.2016 23:06врятли суммы там были довольно большие (крупный заказчик)
к примеру аудит кода по безопасности что нам делали был около 1 млн рублей (точную сумму написать не могу nda), но чтобы понять что это не тысяча рублей.
при этом я не отрицаю что на все фитчи или хотелки надо ТЗ (без ТЗ результат ХЗ), но тут скорее был просто крайне криворукий исполнитель, который наворотил такой адский проект, что его никто не смог бы поддерживать(за разумные деньги) кроме тех кто разрабатывал, меня подключили на этапе ввода в промышленную эксплуатацию и введя его в эксплуатацию я очень рад что покинул эту компанию, потому что там будет знатный АД.
Bammbato
16.11.2016 13:41Нет, ну почему же. В статье четко написано, что начинали проект люди не из отрасли и знания в области составляли 0,0. Тут вопрос не из серии «скупой платит дважды», а «какие проблемы могут возникнуть, если вы ничего не понимаете в разработке и работаете с непрофессионалами (дешевым переложением на рынке). Опять же некоторые моменты касаются и того, что работа с ТОП компаниями не всегда может быть на высоте.Как человек из продаж, могу сказать, что бОльшая часть компаний, с которыми я общался при поиске потенциальной компании-разработчика, не умеют работать с потенциальными клиентами. Ну, или у них проектов много и они не особо волнуются об успехе заключения нового договора.
— Но мы вам сразу сделаем и защиту от sql injection, xss, и шифрование и прочее. Да еще и тестирование на 10 Осях и 20 устройствах. Сразу в пакете.
После всех этих костылей и шишек мы нашли новых разработчиков, которые озвучили все необходимые и неучтенные вещи, грамотно их обосновали и мы с улыбкой на глазах подписали договор и оплатили все, что нужно. Еще с бОльшей улыбкой принимали результаты работы и конечный продукт. Проблемы с оплатой не было, была проблема с опытом (его полным отсутствием).Lofer
16.11.2016 21:44Я искренне Вас поздравляю с позитивным результатом.
Но, подозреваю, что не оплати бы всякие свои аудиты кода (которые вы инициировали явно не просто так) — вы бы не улыбались подписывая второй контракт и вряд ли бы объяснения пали на благодатную почву.
Есть такая проблема с Клиентами, когла ты понимаешь. что он не опытный, а времени или возможности «прокачивать» его просто нет. Тогда настоятельно рекомедуешь Клиенту, делать с «самого простого и необходимого», а на следующих итерациях, будем просто «наращивать мясо» на продукт, заодно и «прокачивая» Клиента. Но, есть поганый политический момент, когда приходит Тот Парень и начинает тыкать пальцем «в косяки», хотя это заложенные «точки расширения». Очень сложный момент.
Как говорится — ни одно доброе дело не должно остаться безнаказанным.
Alyery
17.11.2016 13:35>> бОльшая часть компаний, с которыми я общался при поиске потенциальной компании-разработчика, не умеют работать с потенциальными клиентами. Ну, или у них проектов много и они не особо волнуются об успехе заключения нового договора.
Как правило, срабатывает именно второй вариант.
Когда есть текущая загрузка и потенциал подписать 2-3 крупных проекта от заказчика с именем, на стартаперов (извините за ругательство), времени тратиться не хочется. Выхлоп несоизмеримый даже при равнозначных рисках.
Да, по-человечески это может выглядеть не очень красиво, но с точки зрения бизнеса — всё логично. Благотворительность — она обычно некоммерческая.
Radiocity
15.11.2016 14:34+15Кейс описан, но точных данных и примеров кода нет. Вроде и реклама, но нет ссылок или упоминаний компании. Время потрачено впустую.
roboter
15.11.2016 15:00+12Вот бы версию подрядчиков услышать.
Нереализованные функции
— были ли они в изначальном ТЗ?
Срыв сроков в 2 раза
— правило умножать сроки на 2, не не слышали :)
у нашего партнера просто закончились деньги
— получается фиксированная плата за проект, испрвление багов это тоже часть процесса разработки
кеширование, безопасность
— конечно же оговорена в ТЗ?
которые обязательно возникнут
— не иначе как кристальный шар нужен.
Areso
15.11.2016 16:10Вы-таки предлагаете умножать на 4?)
Подрядчик, если не глуп, тоже закладывает временные риски на отладку/«уточнения» функционала. Тоже в два раза. Если у подрядчика менеджер не делает это, то, я уверен, это делает разработчик, когда прикидывает предстоящий фронт работ. Иногда люди перестраховываются, разработчик умножил на 2, менеджер на 2, да и заказчик подумал «все равно сроки сорвут» и тоже умножил сроки на 2. В итоге, восьмикратно умноженное количество времени, и, почти наверняка, денег.roboter
15.11.2016 16:28лучше на 16 :)
Просто нужно понимать что это эфемерное состояние.
Да и тестирование в сроки лучше не включать, но учитывать что оно тоже будет.
valexlg
15.11.2016 16:50у нашего партнера просто закончились деньги
— получается фиксированная плата за проект, испрвление багов это тоже часть процесса разработки
они были описаны в ТЗ?Bammbato
15.11.2016 16:50Ну конечно, в договоре есть пункт об исправлении возникших багов, при условии, что в код никто сторонний не «вмешивался».
ilyaplot
15.11.2016 16:05+13Если наняли начинающих программистов за копейки без полного списка желаемого функционала с описанием, то переименуйте пост в «Как потерять миллионы, делая непонятно что непонятно с кем»
Bammbato
15.11.2016 16:46+3Идея здравая, пожалуй так и сделаю.
ilyaplot
15.11.2016 18:01+1Удивлен, не думал, что это произойдет, однако, суть была искажена.
KostaArnorsky
15.11.2016 21:16+1Вот так и работали! Ждем статью от второй стороны: «Как потерять нервы, реализуя непонятно что непонятно для кого».
А по теме — нашла коса на камень. Если у вас нет ни малейшего представления о разработке: наймите к себе того, кто имеет. И опцион будет не лишним предложить. Это не гарантия, да и найти хорошего партнера тоже не просто, но это самый первый логичный шаг для начала работы в области, в которой не разбираешься.
keleg
15.11.2016 16:26+4Помнится, в 1С проектах мы придерживались такой формулы.
Если точно знаешь что делать и уже делал много раз — +30% запаса времени
Если знаешь что и как делать и есть детальное ТЗ — время умножается на два
Если понятно что, но непонятно как — время умножается на три.
Если непонятно что — выяснять!
jetcar
15.11.2016 16:51+2большая вероятность что и сам заказчик виноват, так как написано выше, что не было знаний о разработке, потому и ТЗ наверно было очень кривое и постоянно менялось, потому аджайл и практикуют чтоб заказчик был ближе к разработчику чтоб через сломанный телефон требования передавались, а почти напрямую.
в прошлой фирме ситуация была похоже тока я со стороны разработчиков, тут и заказчик был такой который и сам не знает что хочет, но и местный менеджмент не особо пытался чтото исправить, потому на исправления времени почти не давалось, а главное было налепить кучу непродуманного функционала, после срыва очередного срока, наконец удалось убедить что надо написаное переделать иначе новое уже не влезет, смогли переписать и многое исправить, но после этого всё продолжилось по старому, и в конце проэкт забросили, так как приобрели компанию с аналогичным продуктом, но пока без нужного количества фич, но там ситуация не лучше уже 2 года прошло, а единственный клиент не хочет на новый продукт переходить потому что он получился ещё хуже, плохо ещё то что заказчик внутренний, а потому не его деньги тратяться на разработку и он вроде как в этом не виноват вовсе, это всё плохие програмисты :DBammbato
15.11.2016 16:54+1Да, именно так.
Статья не о том, что «все дураки, а мы гардемарины».
И мы из-за незнания разных тонкостей кучу вещей не учли, и с нами в общем-то работали «есть вопросы — хорошо, нет вопросов — еще лучше». Опять же старался это и описать, на что ориентироваться при выборе партнера.
Lofer
15.11.2016 17:04Колоссальные операционные расходы, которые мы понесли из-за срыва сроков сдачи проекта и дебаг;
Интересно было бы посмотреть, как строился бюджет проекта. Есть некоторые эмпирические метрики предварительной оценки бюджета разработки.
Исправление багов по принципу «когда у программистов будет время»;
Это вообще беспредел какой-то, но вряд ли компания просто так отказалась бы от денег :)
Хотя, если Вы отказались от части «тестирование» и сказали что «будем тестировать сами» — не вижу оснований для претензии.
на Solaris приводились цифры что разработка ~33% времени. и ~66% тестирование.poxu
16.11.2016 08:42Исправление багов по принципу «когда у программистов будет время»;
Это вообще беспредел какой-то, но вряд ли компания просто так отказалась бы от денег :)Сказано же, что у подрядчика в определённый момент закончились деньги. Видимо разработка по fixed price, соответственно денег за время потраченное на исправление багов видимо никто не предлагал.
Bammbato
16.11.2016 13:29Да, фикс за проект. Деньги закончились у разработчика свои, а не наши. Был фикс за проект, включена поддержка проекта в работающем состоянии, исправление багов в случае, если в код не лез никто со стороны.
Платящих деньги проектов у нашего партнера оказалось не много, и партнер просто не справился с кассовым разрывом. То есть нам не смогли реализовать часть прописанного в ТЗ функционала, так как просто не чем было платить зп программистам, которые без этой зп работать не хотели :) Ну и туда же отнеслись и баги, которые так же исправлять нужно, а это время, за которое нужно платить сотрудникам, на которые нужны деньги, которых нет. Вот такой замкнутый круг и вышел.
search
15.11.2016 17:07+2Не знаю как другие программисты, а лично я бегу прочь от неопытных заказчиков и фиксд-прайс проектов. Комбинация: неопытнай заказчик + любой программист = проект-урод, о котором потом стыдно вспоминать.
Terras
15.11.2016 23:43-1Поэтому и нужны менеджеры, которые будут вести заказчика и тянуть с него деньги.
taujavarob
15.11.2016 21:26+1Хм. Если вспомнить из какого «мусорного кода» появились миллиардные проекты (потом, потом ...). :-)
igsceo
16.11.2016 13:25Как новичку в подборе кадров нашлись отличные кейсы и советы, которые буду использовать. Было довольно интересно читать!
mr_sw
17.11.2016 16:54Спасибо за статью!
Я представляю как раз другую сторону — свою студию полного цикла. Поэтому было интересно почитать видение общего процесса со стороны заказчика.
Был удивлен, что студии из ТОПа предоставляют такое качество продукта и сервиса. Сейчас конкуренция среди студий довольно высокая, советуем обратить внимание на студии не только из столиц.
AllexIn
Когда мне говорят — сделай клон вот этого приложения(Под другую платформу, или с другим дизайном или еще что-то) — я сразу говорю: давайте тех задание.
Делать по запросу «вот также как тут» я не буду впринципе. Нельзя по внешнему виду приложения понять что и как.
Тоже самое и с исходными кодами чаще всего. Чего мне на них смотреть? Дайте мне документацию на API, макеты, workflow диаграмму. А показывать приложение мне не надо. Я всё равно по показу ничего не сделаю.
Это просто ваша догадка, скорее всего не имеющая никакого отношения к реальности.
Bammbato
Полностью согласен, подход крайне правильный. К сожалению, потенциальный партнер этого правила видимо не придерживался. Ни API, ни исходники, ни работающее приложение смотреть по каким-то причинам не захотели и каких-то дополнительных данных не запрашивали. Опять же причин не предоставить их нет, мы бы с большой радостью.
Может быть, но хотелось бы отметить, что сформирована она была на основания общения с человеком, работающим в данной компании.
KlimovDm
И очень странно, что вы сделали далеко идущие выводы из за такого инсайда. Один только этот пример достаточно характеризует вас, как заказчика. Вместо того, чтобы обсудить план работ (включая привлекаемых специалистов для его выполнения) вы предпочитаете доверять непонятно чему.