Для начала немного истории. 1с программные продукты до 8 версии были таковыми, что их мог поддерживать один человек. Этот человек рассматривался как очень грамотный пользователь, платформа, как известно, не является средой объектно-ориентированного программирования. Это некий конструктор, из которого можно получить многое, но в рамках заложенных известных правил.
1С -ники как пчелки поддерживали системы разной сложности – больше конечно для мелких фирмочек, поскольку действительно большие объемы информации семерка не выдерживала. Истории про то как отчетик формировался всю ночь, чтоб утром посмотреть… Ну в общем, фирмочки росли, росли и 1С решила выпустить новую платформу, для подросшего мелкого и среднего бизнеса.
Ну и конечно, на этой платформе воплотились мечты 1с в создании конкурента для всяких ERPи иже с ними трехбуквенно абривиатурных системам. УПП родилась.
Только вот принципы работы 1Сника остались прежними. Одинокий волк чего-то там поддерживает.
Универсальность она конечно хороша. Когда надо сэкономить. Надо чтоб человек и пользователя разной степени адекватности понял, и ТЗ написал и архитектуру системы знал, и код писал, и работы сдал и того же пользователя научил и доказал что он сделал то что доказывали.
И получается как в белом солнце пустыни.
Одна жена любит, одна одежду шьет, одна пищу варит, одна детей кормит. И все одна? - Ничего не попишешь. - Тяжелооо. - Конечно, тяжело
Не будем рассуждать, как жена выполняет свои обязанности, когда работает как дом быта, просто представим необходимые познания и навыки 1Сника на хорошем таком проекте, где надо не просто пару отчетов дописать.
1) Человек должен хорошо понимать предметную область разработки. То есть видеть систему глазами заказчиками. Желательно говорить с пользователями на одном языке и уметь трансформировать слова в удобоваримое, в то, что может понять и заказчик, и можно будет использовано при разработке. Я думаю, что понимание, что же нужно сделать – достаточно важный момент при первоначальной договоренности. Чтобы потом не было печально известных справедливых воплей заказчика «А мне же обещали, что будет ВСЕ, да тут не ВСЕ, я же с этим работать не могу, ОНО не работает, да я на вас в СУД… в ТЗ же явно написано ВСЕ!» Умение составить документацию нужно, чтобы ограничить ответственность разработчика и втолковать заказчику, что «Все ходы записаны» и про это договорились, а остальные «хотелки» позже и за отдельные деньги.
Почему то когда ДОМ строят, это понятно. А когда систему, не совсем.
Не нужно объяснять, что деловое отношение к процессу поднимает подрядчика в глазах заказчика. А желание побыстрее пройти этап описание требований к системе, мол «все равно никто ничего не читает, и потом все поменяется сто раз», и побыстрее бы программировать начать чревато тем, что все что написано, придется делать. Потому что заказчики как раз программировать не умеют, а договоры читать, вот это они умеют. И если обещали ВСЕ, так берите все ЭТО и делайте. То есть по договору, и ТЗ где написано ВСЕ, возможны два варианта:
- в случае если подрядчик хочет доказать, что они выполняет свои обязательства, то попадают в рабство, пообещав сделать ВСЕ за ограниченную сумму денег;
- или подрядчик не стараются сделать ВСЕ, оставляют обиженного заказчика, который второй раз с новым заказам не пройдет, поскольку обещали, и нехорошие, не сделали того что обещали.
2) Человек должен знать архитектуру готового продукта. В голове должно уместиться структура базы данных, взаимосвязи и алгоритмы. Нужно вписать в то, что уже придумала команда разработчиков (одна – российская, и вторая – украинская дополнила), все пожелания заказчика. Так чтоб было красиво, удобно и не стыдно показать кому то.
Насколько это легко можно узнать, грубо прикинув количество объектов метаданных в УПП.
Еще бы хорошо знать, как это делать, чтобы соответствовало стандартам разработки, интерфейс был интуитивно понятным, и можно было протестировать.
3) Написание кода в больших количествах. То есть решение вопросов алгоритмирования и отладки.
4) Проверка того что сделано, прием работы. Если человек один, то тестировать все придется клиенту. То есть отлавливать ошибки в тот момент работы, то есть когда система должна выдавать документацию а не получается, а фура стоит и её грузить надо, не сильно приятно, я вам скажу. Ну и одна голова хорошо, а полторы всегда лучше было, это правило еще никто не отменял. Да, в одной мелкомягкой фирме 2 тестировщика на одного программиста. Спросите у клиента – как он относится, что на нем будут тестировать, то что напрограммировано?:)
5) Обучение клиентов, написание инструкций пользователям, ответы на телефонные звонки. Ну если будут звонить постоянно, то когда программировать? Но дело важное. Если пользователей много и систему нужно не только напрограммировать, то нужно чтобы кто-то занимался общением с людьми, которые будут с ней работать. Защищать малообщительных программистов, чтоб их не отвлекали, и пользователей от раздраженных программистов, которых отвлекли от любимой работы.
Вывод конечно однозначный. ТЯЖЕЛО одному все это. Быть аналитиком, архитектором проекта, кодером, тестировщиком, консультантом.
Для заказчика вопрос. Я конечно понимаю, что желательно бы подешевле… Но вопрос в следующем. Какие пункты вы бы выбросили, чтобы было подешевле?
Конечно, часто что-то совмещается. Вообще жутко, что получается, когда совмещают аналитика и архитектора. То есть человек должен видеть систему извне глазами пользователя и изнутри, глазами программиста. Вы когда ни будь видели систему с большим количеством фич и «клевых» придумок, которыми никто не пользуется? Хотите такое?
Тестировщиков на 1Совских проектах нет как класса. Типа программист сам все проверит. Вот и получается, озадачен программист, а что он сделал, не знает и не видит никто. Борцы за качество пригодились бы.
Консультанты. Ну это есть. Вот бы еще технические писатели были, чтоб знать, что там с системой сделано.
Представим что проект большой. Какими людьми мы будем комплектовать отдел/команду? Перечнем из разных специальностей с разделением ответственности за каждый участок? Ну чтоб за ТЗ отвечал один отдельно взятый аналитик, за целостность архитектуры системы – архитектор, за код – программисты, за работу с пользователями – консультант? Логично вроде бы. НО НЕТ. Обычно команду наполняют толпой программистов. На вопрос почему, приходит не совсем логичный ответ «потому что программируют». Почему то на стройку не берут только тех, кто кирпичи кладет, а остальное они типа сами как-то. А когда учетную систему делают, то считают, что программист умный, разберется и ТЗ напишет, и код, и инструкцию, и по телефону отвечать будет.
Еще есть вопрос про необходимость технического лидера, как ответственного за организацию работы и загруженность сотрудника. То есть человек, который планирует работу вплоть до дня и недели и знает, в каком состоянии проект, что там происходит и соответственно отвечает за организацию работ. Он отвечает и за отсутствие переработок, и за то чтоб проект когда ни будь закончился.
Сейчас кризис, люди задумались про управление и про экономию. Если брать на каждую функцию отдельного человека, то это обойдется по стоимости в 1 зарплату в месяц. Если специалист нужен хороший, то и зарплата тоже нужна хорошая.
Если совмещать функции, или проигнорировать необходимость аналитика, тестировщика и консультанта, то можно сэкономить. На каком этапе управления анализ - планирование – воплощение – контроль экономить будем? Какой из них выбросим?
Тогда просто нужно посчитать, во что обойдется проекту отсутствие нужного специалиста. Готовы мы рискнуть стоимостью всего проекта?
Как на стройке. На ком будем экономить? На архитекторе-проектировщике, дизайнере, прорабе, роботягах- строителях, приемной комиссии?
