Нет, ну почему же. В статье четко написано, что начинали проект люди не из отрасли и знания в области составляли 0,0. Тут вопрос не из серии «скупой платит дважды», а «какие проблемы могут возникнуть, если вы ничего не понимаете в разработке и работаете с непрофессионалами (дешевым переложением на рынке). Опять же некоторые моменты касаются и того, что работа с ТОП компаниями не всегда может быть на высоте.Как человек из продаж, могу сказать, что бОльшая часть компаний, с которыми я общался при поиске потенциальной компании-разработчика, не умеют работать с потенциальными клиентами. Ну, или у них проектов много и они не особо волнуются об успехе заключения нового договора.
— Но мы вам сразу сделаем и защиту от sql injection, xss, и шифрование и прочее. Да еще и тестирование на 10 Осях и 20 устройствах. Сразу в пакете.
После всех этих костылей и шишек мы нашли новых разработчиков, которые озвучили все необходимые и неучтенные вещи, грамотно их обосновали и мы с улыбкой на глазах подписали договор и оплатили все, что нужно. Еще с бОльшей улыбкой принимали результаты работы и конечный продукт. Проблемы с оплатой не было, была проблема с опытом (его полным отсутствием).
Да, фикс за проект. Деньги закончились у разработчика свои, а не наши. Был фикс за проект, включена поддержка проекта в работающем состоянии, исправление багов в случае, если в код не лез никто со стороны.
Платящих деньги проектов у нашего партнера оказалось не много, и партнер просто не справился с кассовым разрывом. То есть нам не смогли реализовать часть прописанного в ТЗ функционала, так как просто не чем было платить зп программистам, которые без этой зп работать не хотели :) Ну и туда же отнеслись и баги, которые так же исправлять нужно, а это время, за которое нужно платить сотрудникам, на которые нужны деньги, которых нет. Вот такой замкнутый круг и вышел.
Но тут все дело в том, что какие-то базовые вещи — понятие очень растяжимое, как вы понимаете.
Если включить все в «базовые вещи» и когда вам покажут ценник в 10 рублей, то вы скажете, а че так дорого?
Вон у Васи и Ко, за 2 рубля :)
Согласен, но опять же тут вопрос и нашей неопытности.
Кеширование — разное бывает, стоимость его разработки будет тоже разная в зависимости от…
Загрузка страницы за 1 сек тоже может быть «багом» или еще чем, может быть с сервером связано или еще с чем, так что тут тоже все относительно.
Сервер работает как часы *сплевывает 3 раза через плече*. Проблему исправили, больше она не возникала.
т.е. заказывая разработку, вы должны понимать, что потом должна быть поддержка т.к. никто никогда не напишет вам ничего, что не надо исправлять и «допиливать».
С возникающими проблемами согласен, те же пользовательские сценарии сколько не гоняй, все равно что-то, да вылезет. Но есть вещи, которые прогнозируются уже на этапе составления архитектуры — нагрузки, объем контента, количество запросов. Если в ТЗ написано, что проект должен держать одновременно 100.000 пользователей, то странно, что все сдувается на отметке 1000 :)
Да, именно так.
Статья не о том, что «все дураки, а мы гардемарины».
И мы из-за незнания разных тонкостей кучу вещей не учли, и с нами в общем-то работали «есть вопросы — хорошо, нет вопросов — еще лучше». Опять же старался это и описать, на что ориентироваться при выборе партнера.
Итог работы после независимого код-ревью
А в тз обо всем этом говорилось?
А то как бы писать о том чего нет, если вы этого не запрашивал — не хорошо.
Понадеялись, что какие-то вещи являются само собой разумеющимися, и из-за отсутствия какого-либо опыта в этой области оставили их на совесть разработчика, сами дураки. Да, какие-то вещи описывались, какие-то проговаривались устно, какие-то не описывались.
Проблема в том, что мы считали, что какие-то вещи, которые должны быть де-факто у каждого проекта.
Например, загрузка главной страницы не должна из 1 секунды превращаться в минуту через месяц после запуска проекта. Да, можно говорить об отсутствии кеширования в ТЗ, как и можно говорить об отсутствии здравого смысла не делать его, при прогнозировании данной проблемы в такие короткие сроки.
Забегая вперед скажу, что с нынешними разработчиками работа строилась уже с бОльшим пониманием процессов на основании старых косяков, хотя во многом старались доверять их профессионализму. Закрыли кучу потенциальных проблем, о которых мы не знали, не смогли бы спрогнозировать, и уж тем более описать в ТЗ. Тут вопрос, конечно, все равно к скиллам, опыту и порядочности команды разработчиков.
Когда мне говорят — сделай клон вот этого приложения(Под другую платформу, или с другим дизайном или еще что-то) — я сразу говорю: давайте тех задание.
Делать по запросу «вот также как тут» я не буду впринципе. Нельзя по внешнему виду приложения понять что и как.
Тоже самое и с исходными кодами чаще всего. Чего мне на них смотреть? Дайте мне документацию на API, макеты, workflow диаграмму. А показывать приложение мне не надо. Я всё равно по показу ничего не сделаю.
Полностью согласен, подход крайне правильный. К сожалению, потенциальный партнер этого правила видимо не придерживался. Ни API, ни исходники, ни работающее приложение смотреть по каким-то причинам не захотели и каких-то дополнительных данных не запрашивали. Опять же причин не предоставить их нет, мы бы с большой радостью.
Это просто ваша догадка, скорее всего не имеющая никакого отношения к реальности.
Может быть, но хотелось бы отметить, что сформирована она была на основания общения с человеком, работающим в данной компании.
После всех этих костылей и шишек мы нашли новых разработчиков, которые озвучили все необходимые и неучтенные вещи, грамотно их обосновали и мы с улыбкой на глазах подписали договор и оплатили все, что нужно. Еще с бОльшей улыбкой принимали результаты работы и конечный продукт. Проблемы с оплатой не было, была проблема с опытом (его полным отсутствием).
Платящих деньги проектов у нашего партнера оказалось не много, и партнер просто не справился с кассовым разрывом. То есть нам не смогли реализовать часть прописанного в ТЗ функционала, так как просто не чем было платить зп программистам, которые без этой зп работать не хотели :) Ну и туда же отнеслись и баги, которые так же исправлять нужно, а это время, за которое нужно платить сотрудникам, на которые нужны деньги, которых нет. Вот такой замкнутый круг и вышел.
Согласен, но опять же тут вопрос и нашей неопытности.
Сервер работает как часы *сплевывает 3 раза через плече*. Проблему исправили, больше она не возникала.
С возникающими проблемами согласен, те же пользовательские сценарии сколько не гоняй, все равно что-то, да вылезет. Но есть вещи, которые прогнозируются уже на этапе составления архитектуры — нагрузки, объем контента, количество запросов. Если в ТЗ написано, что проект должен держать одновременно 100.000 пользователей, то странно, что все сдувается на отметке 1000 :)
Статья не о том, что «все дураки, а мы гардемарины».
И мы из-за незнания разных тонкостей кучу вещей не учли, и с нами в общем-то работали «есть вопросы — хорошо, нет вопросов — еще лучше». Опять же старался это и описать, на что ориентироваться при выборе партнера.
Понадеялись, что какие-то вещи являются само собой разумеющимися, и из-за отсутствия какого-либо опыта в этой области оставили их на совесть разработчика, сами дураки. Да, какие-то вещи описывались, какие-то проговаривались устно, какие-то не описывались.
Проблема в том, что мы считали, что какие-то вещи, которые должны быть де-факто у каждого проекта.
Например, загрузка главной страницы не должна из 1 секунды превращаться в минуту через месяц после запуска проекта. Да, можно говорить об отсутствии кеширования в ТЗ, как и можно говорить об отсутствии здравого смысла не делать его, при прогнозировании данной проблемы в такие короткие сроки.
Забегая вперед скажу, что с нынешними разработчиками работа строилась уже с бОльшим пониманием процессов на основании старых косяков, хотя во многом старались доверять их профессионализму. Закрыли кучу потенциальных проблем, о которых мы не знали, не смогли бы спрогнозировать, и уж тем более описать в ТЗ. Тут вопрос, конечно, все равно к скиллам, опыту и порядочности команды разработчиков.
Полностью согласен, подход крайне правильный. К сожалению, потенциальный партнер этого правила видимо не придерживался. Ни API, ни исходники, ни работающее приложение смотреть по каким-то причинам не захотели и каких-то дополнительных данных не запрашивали. Опять же причин не предоставить их нет, мы бы с большой радостью.
Может быть, но хотелось бы отметить, что сформирована она была на основания общения с человеком, работающим в данной компании.