Клиенту понадобился обычный сайт-визитка, ничего не обычно все довольно примитивно, как говорится "нужен, чтобы был". Но помимо этого, главные требования были к функционалу сайта, из них понял, что клиент хочет сайт - crm систему.
Т.е. имеется некое кол-во сотрудников, работающие по сдельной оплате и их работу нужно контролировать. Вообщем нужен такой функционал:
- У каждого сотрудника личный кабинет (с заданиями, которые поручены ему);
- Нужен контроль выполнения задания на каждом этапе (отчеты о проделанной работе за день либо за какой-то промежуток);
- Отчет владельцу сайта за день\неделю\месяц (рейтинг работников и т.д.);
- Уведомления о проваливании сроков.
Как-то так. Вопрос, собственно, в том каким образом можно организовать такой функционал?
P.S. не предлагайте пожалуйста Битрикс и готовый CRM системы. Хочется взглянуть в сторону фреймворка Yii. Возможно ли на нем такое развернуть и на сколько сложно это будет сделать?
Для клиента поставьте Sugar CRM (теперь Suite CRM) на отдельном компьютере. Если оно то что ему подходит по функционалу тогда можно думать дальше что делать. Самому писать или готовое доделывать.
Ну если у вас есть полгода-год чтобы сделать прототип CRM, то вперед и с песней.
Прототип выйдет потому что вы еще будете только пилить ядро с основным функционалом.
А затем кто-то начнет пользоваться этим, и окажется что многие тонкости сделаны не так как построен бизнес процесс вашего клиента.
А так же будет постоянно чего-то не хватать и т.д.
И это потому что ТЗ никто не напишет вам, а даже если напишут, всё упомнить тяжело.
Это мой реальный опыт.
Я 3 последних года писал CRM(lptracker) в одиночку.
С "нуля" так сказать.
Вообще согласен, если это действительно будет CRM, описанное в вопросе - это так, мелочи. Потому что основная часть работы - это инструменты сотрудника в личном кабинете. А о них что-то ни слова.
Руслан Шадура: задания, контроль на каждом шагу сделки/или что там и сотрудники это уже достаточно чтобы обозвать CRM. Не говоря об оставшихся пунктах.
Кстати все эти пункты возможно закроются в новой версии LPTrackerа, которая уже почти год пишется параллельно. Там как раз появятся задания, отчеты, KPI сотрудников и даже посчитать зарплату автоматически можно будет. Правда когда её запустят не знаю. Я там уже не работаю))
Поэтому я бы не советовал вообще даже пытаться сделать "под себя" без наличия либо команды, либо огромных сроков на разработку..
Руслан Шадура: чтобы банальную отчетность вести, нужно банальные формы для заполнения.
Но на банальных формах далеко не уедешь, в итоге это превратится в обычную базу клиентов.
Ибо зачем вообще вся эта отчетность, если там нельзя будет работать полноценно, а только надо что-то заполнять? Лишняя работа сотрудникам, и никакой пользы.
Руслан Шадура: ага, я тоже когда-то думал, что пишу просто калькулятор заказа. Сейчас на то, что из него выросло, завязано все производство вплоть до учета материалов и расчета зарплат...
Возможно, это же фреймворк.
Если вышеперечисленные требования это всё, то достаточно просто и полностью зависит от вашего уровня.
Но что-то мне подсказывает, что потом появятся дополнительные "хотелки",
которые при неправильной организации и продумывания проекта станут геморроем.
Поэтому по-моему не нужно отказываться от готовых решений (если не уверены в своих силах и будет время в дальнейшем на доделывания), если опыта мало, а было бы достаточно - вы бы про это не спрашивали, а уже написали бы =)
Все возможно. Только учтите, что ТЗ у вас еще нет и не будет до самого конца.
Поэтому не бойтесь собирать прототипы из говна и палок - лишь бы клиент мог прогнать работу этого прототипа в реальном офисе и определиться, чего он на самом деле хочет (обычно - не того, что вы решили сделать по его предварительному описанию). Ну, и аппетит придет во время еды, если проект действительно заработает - его потом годами можно обогащать и полировать.
Ну, а фреймворк (любой) тут даст три плюса:
1. меньше дыр из-за навязанных фреймворком правильных подходов к архитектуре и данным;
2. более вменяемый код, по той же причине - легче будет его переделывать и поддерживать;
3. хотя бы в самых базовых вещах типа авторизации и ACL можно взять готовое, а не велосипедить.
Руслан Шадура: повторяю: ТЗ не будет. То, что вы с заказчиком сейчас считаете ТЗ, с тем, что ему действительно нужно, будет иметь довольно мало общего. Если, конечно, вы собираетесь делать рабочий инструмент, а не просто выполнить заказ от сих до сих.
