Pull to refresh

Comments 43

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


Когда мне говорят — сделай клон вот этого приложения(Под другую платформу, или с другим дизайном или еще что-то) — я сразу говорю: давайте тех задание.
Делать по запросу «вот также как тут» я не буду впринципе. Нельзя по внешнему виду приложения понять что и как.
Тоже самое и с исходными кодами чаще всего. Чего мне на них смотреть? Дайте мне документацию на API, макеты, workflow диаграмму. А показывать приложение мне не надо. Я всё равно по показу ничего не сделаю.

Проект реализовать было можно, но это, скорее всего, была бы не та конфетка

Это просто ваша догадка, скорее всего не имеющая никакого отношения к реальности.
Когда мне говорят — сделай клон вот этого приложения(Под другую платформу, или с другим дизайном или еще что-то) — я сразу говорю: давайте тех задание.
Делать по запросу «вот также как тут» я не буду впринципе. Нельзя по внешнему виду приложения понять что и как.
Тоже самое и с исходными кодами чаще всего. Чего мне на них смотреть? Дайте мне документацию на API, макеты, workflow диаграмму. А показывать приложение мне не надо. Я всё равно по показу ничего не сделаю.

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

Это просто ваша догадка, скорее всего не имеющая никакого отношения к реальности.

Может быть, но хотелось бы отметить, что сформирована она была на основания общения с человеком, работающим в данной компании.
UFO just landed and posted this here
Кстати, та самая компания, которая так «хорошо» реализовала нам проект, переехала по счастливому стечению обстоятельств в «Москва-Сити», что подтверждает теорию о том, что высокие цены и пафосный офис далеко не всегда являются залогом высокого профессионализма.


Петя потратил выручку на новый дорогой офис в «Москва-Сити», а Вася потратил выручку на новых разработчиков/новую аппаратуру/лицензии/запуск нового продукта. В итоге, Петя подтверждает теорию Bammbato, а Вася получает развитие.
Итог работы после независимого код-ревью
А в тз обо всем этом говорилось?
А то как бы писать о том чего нет, если вы этого не запрашивал — не хорошо.
Итог работы после независимого код-ревью
А в тз обо всем этом говорилось?
А то как бы писать о том чего нет, если вы этого не запрашивал — не хорошо.


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

Проблема в том, что мы считали, что какие-то вещи, которые должны быть де-факто у каждого проекта.
Например, загрузка главной страницы не должна из 1 секунды превращаться в минуту через месяц после запуска проекта. Да, можно говорить об отсутствии кеширования в ТЗ, как и можно говорить об отсутствии здравого смысла не делать его, при прогнозировании данной проблемы в такие короткие сроки.

Забегая вперед скажу, что с нынешними разработчиками работа строилась уже с бОльшим пониманием процессов на основании старых косяков, хотя во многом старались доверять их профессионализму. Закрыли кучу потенциальных проблем, о которых мы не знали, не смогли бы спрогнозировать, и уж тем более описать в ТЗ. Тут вопрос, конечно, все равно к скиллам, опыту и порядочности команды разработчиков.
Но тут все дело в том, что какие-то базовые вещи — понятие очень растяжимое, как вы понимаете.
Если включить все в «базовые вещи» и когда вам покажут ценник в 10 рублей, то вы скажете, а че так дорого?
Вон у Васи и Ко, за 2 рубля :)

Кеширование — разное бывает, стоимость его разработки будет тоже разная в зависимости от…
Загрузка страницы за 1 сек тоже может быть «багом» или еще чем, может быть с сервером связано или еще с чем, так что тут тоже все относительно.

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

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

Поэтому как сказал https://habrahabr.ru/post/315332/#comment_9911030, если ему говорят сделай копию, то он хочет ТЗ, ведь у всех разное понимание копий :)
Но тут все дело в том, что какие-то базовые вещи — понятие очень растяжимое, как вы понимаете.
Если включить все в «базовые вещи» и когда вам покажут ценник в 10 рублей, то вы скажете, а че так дорого?
Вон у Васи и Ко, за 2 рубля :)

Согласен, но опять же тут вопрос и нашей неопытности.

Кеширование — разное бывает, стоимость его разработки будет тоже разная в зависимости от…
Загрузка страницы за 1 сек тоже может быть «багом» или еще чем, может быть с сервером связано или еще с чем, так что тут тоже все относительно.

Сервер работает как часы *сплевывает 3 раза через плече*. Проблему исправили, больше она не возникала.

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

С возникающими проблемами согласен, те же пользовательские сценарии сколько не гоняй, все равно что-то, да вылезет. Но есть вещи, которые прогнозируются уже на этапе составления архитектуры — нагрузки, объем контента, количество запросов. Если в ТЗ написано, что проект должен держать одновременно 100.000 пользователей, то странно, что все сдувается на отметке 1000 :)
UFO just landed and posted this here
Хороший исполнитель должен предполагать что заказчик дурак и сам сказать как делать правильно, а не красиво.
Проводя автомобильные аналогии, Вы заказали разработку абстрактной машины с четырьмя колесами, крышей и рулем, на выходе получили два сваренных друг с другом велосипеда с запряженной костылями лошадью и прикрученным синей изолентой пляжным зонтиком (или Лада Калину). После чего удивляетесь, что у нее нет адаптивных систем безопасности, круиз-контроля, разгона до 100 за 3 секунды и шильдика S63 AMG — 21й век на дворе ведь, это само собой разумеющиеся вещи.
Ну, мы не на столько наглые заказчики. АКП, 4 сидения и сигнализация было бы вполне достаточно.
>Ну, мы не на столько наглые заказчики. АКП, 4 сидения и сигнализация было бы вполне достаточно.

Заказчик может придраться к чему угодно.

— Я недавно смотрел авто, всё на месте и «АКП, 4 сидения и сигнализация» — но кнопочки какие то такие уродливые и из такого пластика что просто… плакать хочется — и это в 21 веке то!?

P.S. То что у авто в 2016 году задние тормоза — барабанные — это уже, ладно, типа фича.

P.P.S. Недавно выбирал холодильник… Самсунг. Рядом стояли российской сборки и настоящий -из Кореи (в 1.5 раза дороже) — да, там тот же компрессор- но пластмасса фурнитуры настоящего корейца (на дверце которая) в два раза толще!!!

Эх. Аналогии.
к сожалению работал с подобными исполнителями

этого нет в тз, как можно в тз написать что приложение должно быть безопасным? не должно быть sql injection или xss, как это проверить? откуда заказчик должен знать о существование sql injection и xss? если он знает что это такое и как проверить, возможно ему уже не требуется разработка?
Совершенно верно. Не всегда заказчик и исполнитель общаются на одном языке.
К сожалению работал с такими Заказчиками. :)
— Хотим вот Такую Крутую Штуку.
— Ок. Можем сделать. 1 000 денег.
— Не! Ребята, вы офигели. Те Парни такое делают за 200 денег!
— Но мы вам сразу сделаем и защиту от sql injection, xss, и шифрование и прочее. Да еще и тестирование на 10 Осях и 20 устройствах. Сразу в пакете.
— Не парни, вы нас на бабки разводите! А вот еще Лучший Приятель, сказал что розовые единороги пасутся на радуге! Пошли нафиг Злые Программеры!!!
врятли суммы там были довольно большие (крупный заказчик)

к примеру аудит кода по безопасности что нам делали был около 1 млн рублей (точную сумму написать не могу nda), но чтобы понять что это не тысяча рублей.

при этом я не отрицаю что на все фитчи или хотелки надо ТЗ (без ТЗ результат ХЗ), но тут скорее был просто крайне криворукий исполнитель, который наворотил такой адский проект, что его никто не смог бы поддерживать(за разумные деньги) кроме тех кто разрабатывал, меня подключили на этапе ввода в промышленную эксплуатацию и введя его в эксплуатацию я очень рад что покинул эту компанию, потому что там будет знатный АД.
Нет, ну почему же. В статье четко написано, что начинали проект люди не из отрасли и знания в области составляли 0,0. Тут вопрос не из серии «скупой платит дважды», а «какие проблемы могут возникнуть, если вы ничего не понимаете в разработке и работаете с непрофессионалами (дешевым переложением на рынке). Опять же некоторые моменты касаются и того, что работа с ТОП компаниями не всегда может быть на высоте.Как человек из продаж, могу сказать, что бОльшая часть компаний, с которыми я общался при поиске потенциальной компании-разработчика, не умеют работать с потенциальными клиентами. Ну, или у них проектов много и они не особо волнуются об успехе заключения нового договора.

— Но мы вам сразу сделаем и защиту от sql injection, xss, и шифрование и прочее. Да еще и тестирование на 10 Осях и 20 устройствах. Сразу в пакете.

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

Но, подозреваю, что не оплати бы всякие свои аудиты кода (которые вы инициировали явно не просто так) — вы бы не улыбались подписывая второй контракт и вряд ли бы объяснения пали на благодатную почву.
Есть такая проблема с Клиентами, когла ты понимаешь. что он не опытный, а времени или возможности «прокачивать» его просто нет. Тогда настоятельно рекомедуешь Клиенту, делать с «самого простого и необходимого», а на следующих итерациях, будем просто «наращивать мясо» на продукт, заодно и «прокачивая» Клиента. Но, есть поганый политический момент, когда приходит Тот Парень и начинает тыкать пальцем «в косяки», хотя это заложенные «точки расширения». Очень сложный момент.
Как говорится — ни одно доброе дело не должно остаться безнаказанным.
>> бОльшая часть компаний, с которыми я общался при поиске потенциальной компании-разработчика, не умеют работать с потенциальными клиентами. Ну, или у них проектов много и они не особо волнуются об успехе заключения нового договора.

Как правило, срабатывает именно второй вариант.

Когда есть текущая загрузка и потенциал подписать 2-3 крупных проекта от заказчика с именем, на стартаперов (извините за ругательство), времени тратиться не хочется. Выхлоп несоизмеримый даже при равнозначных рисках.

Да, по-человечески это может выглядеть не очень красиво, но с точки зрения бизнеса — всё логично. Благотворительность — она обычно некоммерческая.
UFO just landed and posted this here
Вот бы версию подрядчиков услышать.

Нереализованные функции
— были ли они в изначальном ТЗ?

Срыв сроков в 2 раза
— правило умножать сроки на 2, не не слышали :)

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

кеширование, безопасность
— конечно же оговорена в ТЗ?
которые обязательно возникнут
— не иначе как кристальный шар нужен.
Вы-таки предлагаете умножать на 4?)
Подрядчик, если не глуп, тоже закладывает временные риски на отладку/«уточнения» функционала. Тоже в два раза. Если у подрядчика менеджер не делает это, то, я уверен, это делает разработчик, когда прикидывает предстоящий фронт работ. Иногда люди перестраховываются, разработчик умножил на 2, менеджер на 2, да и заказчик подумал «все равно сроки сорвут» и тоже умножил сроки на 2. В итоге, восьмикратно умноженное количество времени, и, почти наверняка, денег.
лучше на 16 :)
Просто нужно понимать что это эфемерное состояние.
Да и тестирование в сроки лучше не включать, но учитывать что оно тоже будет.
у нашего партнера просто закончились деньги
— получается фиксированная плата за проект, испрвление багов это тоже часть процесса разработки

они были описаны в ТЗ?
Ну конечно, в договоре есть пункт об исправлении возникших багов, при условии, что в код никто сторонний не «вмешивался».
Если наняли начинающих программистов за копейки без полного списка желаемого функционала с описанием, то переименуйте пост в «Как потерять миллионы, делая непонятно что непонятно с кем»
Идея здравая, пожалуй так и сделаю.
Вот так и работали! Ждем статью от второй стороны: «Как потерять нервы, реализуя непонятно что непонятно для кого».
А по теме — нашла коса на камень. Если у вас нет ни малейшего представления о разработке: наймите к себе того, кто имеет. И опцион будет не лишним предложить. Это не гарантия, да и найти хорошего партнера тоже не просто, но это самый первый логичный шаг для начала работы в области, в которой не разбираешься.
Да, идея здравая, жаль только, что запоздалая :(
Помнится, в 1С проектах мы придерживались такой формулы.
Если точно знаешь что делать и уже делал много раз — +30% запаса времени
Если знаешь что и как делать и есть детальное ТЗ — время умножается на два
Если понятно что, но непонятно как — время умножается на три.
Если непонятно что — выяснять!
большая вероятность что и сам заказчик виноват, так как написано выше, что не было знаний о разработке, потому и ТЗ наверно было очень кривое и постоянно менялось, потому аджайл и практикуют чтоб заказчик был ближе к разработчику чтоб через сломанный телефон требования передавались, а почти напрямую.
в прошлой фирме ситуация была похоже тока я со стороны разработчиков, тут и заказчик был такой который и сам не знает что хочет, но и местный менеджмент не особо пытался чтото исправить, потому на исправления времени почти не давалось, а главное было налепить кучу непродуманного функционала, после срыва очередного срока, наконец удалось убедить что надо написаное переделать иначе новое уже не влезет, смогли переписать и многое исправить, но после этого всё продолжилось по старому, и в конце проэкт забросили, так как приобрели компанию с аналогичным продуктом, но пока без нужного количества фич, но там ситуация не лучше уже 2 года прошло, а единственный клиент не хочет на новый продукт переходить потому что он получился ещё хуже, плохо ещё то что заказчик внутренний, а потому не его деньги тратяться на разработку и он вроде как в этом не виноват вовсе, это всё плохие програмисты :D
Да, именно так.
Статья не о том, что «все дураки, а мы гардемарины».
И мы из-за незнания разных тонкостей кучу вещей не учли, и с нами в общем-то работали «есть вопросы — хорошо, нет вопросов — еще лучше». Опять же старался это и описать, на что ориентироваться при выборе партнера.
Колоссальные операционные расходы, которые мы понесли из-за срыва сроков сдачи проекта и дебаг;


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

Исправление багов по принципу «когда у программистов будет время»;


Это вообще беспредел какой-то, но вряд ли компания просто так отказалась бы от денег :)
Хотя, если Вы отказались от части «тестирование» и сказали что «будем тестировать сами» — не вижу оснований для претензии.
на Solaris приводились цифры что разработка ~33% времени. и ~66% тестирование.
Исправление багов по принципу «когда у программистов будет время»;

Это вообще беспредел какой-то, но вряд ли компания просто так отказалась бы от денег :)

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

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

Платящих деньги проектов у нашего партнера оказалось не много, и партнер просто не справился с кассовым разрывом. То есть нам не смогли реализовать часть прописанного в ТЗ функционала, так как просто не чем было платить зп программистам, которые без этой зп работать не хотели :) Ну и туда же отнеслись и баги, которые так же исправлять нужно, а это время, за которое нужно платить сотрудникам, на которые нужны деньги, которых нет. Вот такой замкнутый круг и вышел.
Не знаю как другие программисты, а лично я бегу прочь от неопытных заказчиков и фиксд-прайс проектов. Комбинация: неопытнай заказчик + любой программист = проект-урод, о котором потом стыдно вспоминать.
Поэтому и нужны менеджеры, которые будут вести заказчика и тянуть с него деньги.
Хм. Если вспомнить из какого «мусорного кода» появились миллиардные проекты (потом, потом ...). :-)
Далеко не каждый мусорный код превращается в миллиардный проект.
Как новичку в подборе кадров нашлись отличные кейсы и советы, которые буду использовать. Было довольно интересно читать!
Спасибо за статью!
Я представляю как раз другую сторону — свою студию полного цикла. Поэтому было интересно почитать видение общего процесса со стороны заказчика.
Был удивлен, что студии из ТОПа предоставляют такое качество продукта и сервиса. Сейчас конкуренция среди студий довольно высокая, советуем обратить внимание на студии не только из столиц.
Sign up to leave a comment.

Articles