Комментарии 13
Например, регистрация клиента в вашей программе занимает 30 сек., а просто в Excel'евской таблице 1,5 минуты.
Обычно наоборот. Такова уж природа Excel. Упирать лучше на реальную "многопользовательскость", на возможность разделять доступ к клиентам, передавать от одного менеджера другому, на сохранение знаний о конкретном клиенте и т.п.
Надежность выше, из-за того, что вы используете БД с бэкапом, а не файл на диске.
Файлы тоже отлично бэкапятся, если системный администратор не совсем уж убогий. Тут надо копать глубже и упирать на сохранение всей истории работы с документом и т.д. - это людям близко и понятно, т.к. вечно какие-нибудь разборки мелкие происходят.
Вопрос. Как быть начинающей компании? Для заказчика она все равно что частное лицо. Гарантий, что компания будет работать и через полгода, и через два года, нет никаких.
Согласен, что может быть и так. Чуть позже внесу апдейтами в топик, чтобы ценные замечания не терялись в комментах.
Что касается начинающей компании, то всегда можно сослаться на личный опыт ее владельцев и сотрудников. Вряд ли, совсем молодой специалист будет создавать фирму. А так, наоборот можно сблизиться тем, что надоело работать на дядю - открыл свое дело. Т.е. Вы и ваш клиент находитесь в одной рыночной позиции - вы самостоятельные предприниматели. ИМХО, одно дело, когда ты говоришь с наемным сотрудником и другое с таким же предпринимателем, как и ты сам.
Что касается начинающей компании, то всегда можно сослаться на личный опыт ее владельцев и сотрудников. Вряд ли, совсем молодой специалист будет создавать фирму. А так, наоборот можно сблизиться тем, что надоело работать на дядю - открыл свое дело. Т.е. Вы и ваш клиент находитесь в одной рыночной позиции - вы самостоятельные предприниматели. ИМХО, одно дело, когда ты говоришь с наемным сотрудником и другое с таким же предпринимателем, как и ты сам.
отлично структурированная статья. почти каждый абзац ставит проблему и дает пример ее решения. исключение только про "мелкие доработки". мне кроме анекдота про программиста, сдающего проект ("а вот у меня закончаться деньги и я приду и попрошу у вас немного.") ничего в голову не приходит. как можно "бороться" с такими просьбами?
ИМХО, с такими просьбами можно бороться только приводя аналогии ("вы купили автомобиль, а потом решили поменять местами спидометр и магнитолу") и выставляя смету на доработку.
С другой стороны, если у вас тиражирующийся продукт и эта модификация действительно полезна, то можно сделать в рамках технической поддержки или обновлений.
С другой стороны, если у вас тиражирующийся продукт и эта модификация действительно полезна, то можно сделать в рамках технической поддержки или обновлений.
небольшое количество постоянных клиентов
Совершенно необязательно. Например, практически все издательства суть мелкие предприятия, а клиентов у них могут быть тысячи.
пугать надежностью и качеством
К сожалению, в наших реалиях с невысоким качеством можно столкнуться, имея дело с самыми что ни на есть брендовыми конторами. Этому можно найти объяснение, но легче не станет.
По собственному опыту бороться со "студентами" очень сложно, но думаю это переходной период - все помнят самодельные бухгалтерии начала 90.
Что касается изменений по ходу пьесы, то я обычно показываю график стоимости изменений в зависимости от этапа проекта.
Заказчик посмотрев на стоимость часа на этапе ТЗ и на этапе тестирования думает 3 раза стоит ли это менять и что самое главное менять сейчас или в следующей версии - что для вас полезнее, у вас есть потенциальное продолжение проекта.
В статье не затронут очень важный вопрос - каким образом строить ценообразование продукты. Дешево сразу + поддержка, или дорого и пусть сам мучается. Я думаю те кто выбрали оптимальную схему, достигнут наибольшего успеха, и что греха таить IT сейчас это все больше маркетинг чем программирование.
Что касается изменений по ходу пьесы, то я обычно показываю график стоимости изменений в зависимости от этапа проекта.
Заказчик посмотрев на стоимость часа на этапе ТЗ и на этапе тестирования думает 3 раза стоит ли это менять и что самое главное менять сейчас или в следующей версии - что для вас полезнее, у вас есть потенциальное продолжение проекта.
В статье не затронут очень важный вопрос - каким образом строить ценообразование продукты. Дешево сразу + поддержка, или дорого и пусть сам мучается. Я думаю те кто выбрали оптимальную схему, достигнут наибольшего успеха, и что греха таить IT сейчас это все больше маркетинг чем программирование.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Продажа продуктов и услуг малому бизнесу