Почему разработать мобильное приложение или сайт стоит так дорого и как снизить эту стоимость в 10 раз
Рано или поздно предприниматели, только планирующие открыть свой проект или уже ведущие бизнес, сталкиваются с необходимостью разработки сайта или приложения. И тут два варианта: либо они всё-таки находят большие деньги и вкладывают их в разработку, либо на стадии сметы всё и заканчивается.
Может не по теме. Но вроде бы связана с разработчиками, ценами на проект.
Сегодня дедлайн по проекту. Делаем сайт. Дизайн и верстка готовую нам уже дали, мы должны были его натянуть ее на движок.
Один из программистов нашей команды решил что он лучше разбирается в вопросе, чем дизайнер, маркетолог и весь топ-менеджмент компании на которую мы работаем, и сделал по своему некоторые элементы интерфейса. Сначала не посмотрев на исходную версию дизайна, а потом, когда он их все таки увидел, я вежливо попросил не заниматься отсебятиной, а он обижается и настаивает на том, что бы я показал его "творения" заказчику.
Я, предвидя реакцию заказчика на отклонения от дизайна, по-непонятно каким причинам (потомучто так решил программист - ого причина), хочу уже искать себе другую работу.
У меня иногда возникает такое чувство, что я работаю в палате с пациентами и просто я пока не так сильно поехал, и что я тоже пациент.
Я чувствую что такие ситуации подводят команду, выбивают меня и других коллег из рабочей колеи.
Программист именно настаивает, чтобы я показал результат его свежатинки проджект-менеджеру заказчика. И для меня это большая проблема, так как компания заказчика Московская, не сытые коты там лежат, ИТ-шники в край уже озверели со своими зарплатами, а сроки сдачи проекта уже горят. Недопонимание внутри команды растет из-за того, что один бекенд программист видит ситуацию по-своему и на это уходит огромная куча времени.
Как поступить:
- показать заказчику, что мы отклонились от дизайна, потомучто бекенд программист считает текущее решение блеклым и некрасивым, а полезную информацию он вообще исключил из карточек товаров, "ну потомучто ему так больше нравится";
- ответить программисту в особо жёсткой форме, что бекендщик не должен заниматься вопросами UI, когда его об этом не просят, в его обязанности прямые также не входит срыв сроков проекта, постоянно придумывание сложностей;
- ответить спокойно, что так дальше не пойдет, культурно объяснить почему, подождать недельку-другую, когда к нему вернётся сознание, сохранить отношения с сотрудником, ни в коем случае не увольнять его и не закрывать доступ к серверам, а заказчику пока не сдавать проект в срок;
- вообще ничего никому не говорить, попросить коллег это переделать за день?
Разработчик явно хочет внимания и признания его идей. А мне нужна работа выполненная по ТЗ и не иметь никаких проблем с проджектом. И да и ещё проект сдать. Мы, там, старались, кто-то все ещё не забыл что он работает на заказчика, а не наоборот. Команда то ещё не совсем вся распалась.
Зачем так усложнять всё? Скажи, что покажешь заказчикам. Через часа три - ответили, что хотят, чтобы было как в ТЗ. Спасибо за инициативу, ты молодец, но надо переделать, увы.
С одной стороны вы правы, с другой стороны - такой pipeline как вы описали приводит к тому что часто делают утвержденные, но бессмысленные фичи или теряют бабки.
Программист, вероятно, мог найти готовые реализации некоторых компонентов и не тратить время на реализацию того что в дизайне. Почему бы и не обсудить это?
На новом месте работы советую делать приемку программистами дизайна, и вообще вовлечение их в процесс на этапе проектирования, при этом все должны понимать какую реальную цель вы хотите достичь.
Это проверенный способ сокращать сроки и бюджеты - иногда, например, вместо сложнейшего экрана достаточно сделать экспорт в Excel. Или вместо вздрюкивания всей техподдержки на KPI - иногда отправлять push о том что "сейчас проблема, мы знаем"
На такое мышление хорошо настраивает опыт финансирования стартапа или продуктовой компании.
В аутсорсе всем хочется спихнуть ответственность на заказчика.