Работа над ошибками

Последний проект который я реализовывал была биллинговая система для служб ЖКХ. Проект вместо запланированных 6 месяцев длился более года. В результате работ я сделал для себя отчет «работа над ошибками».

2-хзвеньевое приложение против 3-хзвеньевого.
Изначально было выбраны 3-хзвеньевая архитектура приложения. Выбор был сделан потому, что считалось что 3 звена дают большую гибкость, а 2 звена такую гибкость не дают. Исходили из того, что требуется ограничивать доступ к данным на уровне строк таблицы. Кроме того, планировалось сделать приложение конфигурируемым (типа 1С), дабы позволить пользователю самостоятельно например добавлять свои отчеты и т. д.
Итого: желаемая конфигурируемость не была достигнута, т. к. сроки жали и времени на эксперименты не оставалось. Заказчику откровенно было наплевать на конфигурируемость, он давил на сроки. А используемые 3 звена добавили программистам работы, т. к. они должны были писать больше кода. Использовался WCF сервис SOAP, через которое клиентское приложение получало данные.
Поэтому дам одни совет никогда не принимайте решение реализовывать 3-звена, если нет на то крайней необходимости.

Большой объем вычислений в коде C#.
Начали писать логику всех расчетов в C#. Когда уже все дописали после первых испытаний поняли, что что то у нас не так. Потому что время обработки 180 тыс. услуг составляло 9 часов. Переписали все в хранимые процедуры получили ускорение до 30 минут. Добавили оптимизации. Получили 2 минуты на обработку. Добавили функционала, получили что расчет длится 40 минут.
Итого: если у вас стоит задача обрабатывать данные в большом объеме переносите логику вычислений в хранимые процедуры, нельзя недооценивать их. Они работают с данными существенно быстрее чем ваш код на php, java, c#. И ещё всегда работайте над оптимизацией кода, как сказал один мой знакомый любой проект надо 3 раза переписать, что бы получить конфетку. Надо только при оценке проекта заложить время на рефакторинг.

Работа над проектом в офисе
Одной из ошибок малое общение с клиентом. Точнее мы общались постоянно, но только с одним их представителем. Которые в процессе проекта сменился на другого, тот потом вообще отмазывался, что бы меньше с нами общаться. В итоге я понял следующее. Наш заказчик дагестанский, а также и российский не хочет думать ни о чем. Он хочет следующее, что бы вы пришли к нему, сами в его каше разобрались, написали программу и у него было все в шоколаде, т. е. общаться нужно не тех. представителем заказчика, а напрямую с людьми, которые будут пользоваться программой. Потому как их мнение важнее. И они в конце будут говорить своему руководству довольны они программой или нет. У нас правда был другой сложный момент. Пользователи программы (сотрудники заказчика) привыкли работать со своими программистами. Поэтому нас с нашими вопросами чаще всего отсылали к тех. персоналу заказчика.
Итого: больше общайтесь с клиентом, и его сотрудниками. Если сам клиент в лице руководителя не шарит в предметной области.

Не гибкая методология
Используемая нами методология разработка предполагала одну итерацию. Во многом это было связано с 2 вещами:
1)Мой товарищ работающий в компании заказчика предупредил, что у них очень часто все меняется, и что бы обезопасить себя от проблем с заказчиком, я предпочел сразу составить одно большое ТЗ и делать строго по нему не отходя от него.
2)Заказчик плохо представлял себе, что такое итеративная разработка. В его понятии, я заплатил деньги и должен получить конечный продукт. Принеся к нему, часть продукта, заказчик говорил, все это хорошо, но ты принеси мне рабочий продукт.
Итого: Большие проекты должны быть обязательно итеративные. После каждой итерации необходимо:
Корректировать ТЗ
Корректировать бюджет
Корректировать календарный план

Слабая команда
Команда состояла на 4 стажеров и 1 программиста. 1 Программист это я выполняющий больше функции проектного менеджера нежели разработчика, т. к. когда у тебя в команде 4 человека, то им нужно ставить задачи и контролировать их выполнение. А когда они ещё и стажеры, то необходимо и помогать им в решении их вопросов. Из 4 стажеров к концу проекта 1 стажер набрался хорошей квалификации и стал нормально самостоятельно работать. Остальных в аут.
Итог: подходите очень серьезно к кадрам. Если вы думаете взять стажера, то подумайте о том, что стажер может вам больше мешать, чем помогать. Если стажер слабый и больше создает проблем, то отказаться от него. В остальном постарайтесь подбирать хороших специалистов, но не забывайте, что хорошего специалиста, также необходимо контролировать.

Отвлечение на другие проекты
Тут все понятно. Нельзя отвлекаться на другие проекты, если у вас жесткий календарный план и сроки.

Плохо написанное ТЗ
Это полностью мой косяк. Взялся писать ТЗ. Написал но плохо. Раскрыты были не все моменты. Т. е. снаружи как бы все понятно, но в реальности много непонятного. В итоге заказчик валит все на меня, мол ТЗ плохо составил. А на вопрос, что он это ТЗ согласовывал и почему упустил много моментов, свою вину отказался принимать.
Мой косяк, что не указал например элементарно, что система пишется на программных продуктах MSSQL сервер. Также в ТЗ встречались такие фразы: «система должна позволять получить отчеты в различных разрезах» или « и другие». Такие непонятные фразу вообще должны отсутствовать. Если нет конкретики, вообще лучше не писать.

Недооценка проекта
Это самая основная ошибка, хотя и пишу о ней в конце. Проект был недооценен. Потому что, до конца не представлял себе всего объема работ, что вытекает из неправильно написанного ТЗ. Кроме того, вроде бы есть простая задача посчитать пеню например. Пеня считается легко, но есть нюансы. Которые вылезают в процессе реализации. Поэтому лучше предварительно при предпроектном обследовании стоит не пожалеть время и посадить разработчика свободного пусть напишет тебе алгоритм расчета пени. Пусть пощупает и скажет тебе сколько времени ему нужно на реализацию. Скорее всего, он скажет 2 часа. А что там его считать. Пример: алгоритм расчета пени, это просто берется сумма долга абонента и начисляет 1/300 ставки рефинансирования центробанка на каждые сутки, просроченной задолженности. Вроде бы все легко, но тут начинаются вопросы. Например: необходимо получить количество дней. А их получение зависит от структуры данных как вы храните информацию об абоненте. Причем, например абонент по закону должен оплатить долг до 10 числе следующего месяца. Т. е. если сегодня 15 марта, то вы должны начислять абоненту пеню на его долг за все предыдущие месяца с 1 марта, а на его долг за февраль пеня начисляется только с 10 марта. Причем пеня получается начисляется посуточно. Теперь представьте ситуацию когда абонент пришел и оплатил часть долга. Т. е. пеня должна уже начисляться не на весь долг на начало месяца, а только на ту часть которую он ещё недоплатил.
Итого: очень многое в таких алгоритмах зависит от того как хранить данные в БД. Что вам доступно просто лежит в поле таблицы и можно взять оттуда и посчитать, а что придется вычислять. Поэтому например алгоритм расчета пени в данной системе займет в разработчика неделю как минимум, а потом с доводкой и оптимизацией ещё пару недель. Так что недели 3 он потратит на этот алгоритм. У нас реализации алгоритма расчета пени менялась около 3 раз. Каждый раз по неделе трудозатрат вот вам и 3 недели. Вот и недооценка, вместо первоначальных «да что там на 2 часа работы».

В принципе все, что я хотел я здесь описал. Если что вспомню ещё добавлю.

ВРП регионов

http://antonfromperm.wordpress.com/category/data-analysis/

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