Изменения

На сегодняшний день система «Курьерская служба» отметила своё четырнадцатилетние. За это время её положительно оценили и активно с нами сотрудничают более 300 компаний. Наши партнёры находятся в самых разных странах мира, таки как : Россия, Казахстан, Украина, Белоруссия, Киргизия, Латвия. С помощью нашего сервиса ежедневно 4,5 тысячи курьеров доставляют 60 тысяч отправлений от 11 тысяч клиентов.Сама созданная нами «Курьерская служба» состоит из 207 200 связанных друг с другом таблиц, в некоторых из которых встречается по 50 миллионов записей. Над Мы постоянно работаем над её совершенствованием трудиться целый штат высококлассных специалистов. « – Для чего они нужны?» – спросите Вы. Мир не стоит на месте, он меняется, и мы не отстаём от времени. Если завтра кто-то решит избежать пробок и доставлять корреспонденцию дронами – мы сможем адаптировать систему под его нужды. Если через десять лет откроют телепортацию и будут доставлять заказы с её помощью – мы сможем подстроиться и под этот метод доставкичтобы наши клиенты всегда были впереди конкурентов. Наша команда работает, что бы Вам было удобно!  

Для эффективной работы команда должна быть компактной. Оптимальный размер команды для разработки ПО - 7-15 человек. Это тот объем, который позволяет руководителю дотянуться до каждого сотрудника, проконтролировать работу, объединить усилия всех сотрудников в единый организм и комплексно, целенаправленно решать стратегические задачи. Понятно, что написать Windows с такой командой невозможно, ее нужно сильно расширять. Однако это требует существенного расширения сопутствующего персонала. К сожалению, речь идет не только о найме проект-менеджера на каждую группу по 7 человек (зарплаты которых измеряются сотнями тысяч рублей), но и раздутии штата прочими сотрудниками, напрямую в процессе разработки/сопровождения не занятыми, поскольку работу групп нужно координировать, большую задачу нужно разбить на блоки, требования, функциональность, методы тестирования, интерфейсы взаимодействия которых нужно полностью задокументировать. Объем технической документации при "правильном" подходе занимает больше времени и стоит дороже, чем сам процесс разработки. После разработки каждого куска его надо тестировать отдельными штатными единицами, а потом пытаться склеить эти блоки вместе. В случае же с компактной командой ее можно просто собрать вместе, и сказать: "Давайте сделаем вот это. Ты делаешь это, а ты - вон то, через 2 дня собираемся вместе и проверяем". Поэтому я стараюсь удержать размер команды в оптимальном диапазоне. Пусть мы не можем такими силами взяться за какие-то глобальные мегапроекты, зато предельно эффективно решаем свои конкретные текущие задачи, которые ставят перед нами наши клиенты. Мы, конечно, разбираемся в предметной области. Я начинал свою карьеру с работы курьером еще в 2000-м году, потом в офисе курьерской службы. Коммерческий директор - обязательно с опытом руководящей работы в курьерской службе. Мы лично встречаемся, общаемся с клиентами. Остальные сотрудники обязательно начинают свою работу с изучения предметной области. Полное погружение в нее - обязательное условие нормальной работы каждого сотрудника. К сожалению, большинство разработчиков подходят к своей работе только с позиции "мы умеем писать код, нам заказчик скажет, что написать, мы сделаем". Лично сталкивался с "автоматизаторами", которые только от меня узнавали, что после распределения заказов по курьерам их нужно еще физически на складе сортировать, а не просто скинуть курьерам полученные списки. Поэтому мы прикладываем все усилия к тому, чтобы такими не быть.

<====Экстремальное программирование====В своей работе в разной степени мы используем принципы [https://ru.wikipedia.org/wiki/Экстремальное_программирование экстремального программирования]. Мое самое любимое положение из него - код должен максимально быстро начинать приносить реальную пользу (прибыль!) нашим клиентам. При классическом подходе к разработке, как я уже писал, сначала пишется документация всей доработки, потом разбивается на подзадачи, реализуется, тестируется, отлаживается и т.д., на все это уходит куча времени и денег. Потом ее пытаются сдать заказчику, и тут оказывается, что задачу изначально не совсем так поняли. Чтобы этого всего избежать, мы сходу пишем небольшие куски, и сразу, даже без тестирования, отдаем заказчику. Да, при этом могут быть ошибки. Но заказчик сразу начинает пользоваться, решать свои бизнес--Мызадачи, т.е. экономить деньги. Ошибки, замечания, конечнопожелания, стараемся разбираться которые он обнаруживает уже в предметной областипромышленной эксплуатации, а на на примере [https://ru.wikipedia. Я начинал свою карьеру с работы курьером еще org/wiki/Научный_юмор#Сферический_конь_в_вакууме сферических коней в 2000-м годувакууме], как это делает тестировщик, потом в офисе курьерской службыреальном времени передаются разработчикам и так же быстро устраняются. Коммерческий директор В результате мы получаем огромный прирост эффективности - обязательно с опытом руководящей работы в курьерской служберазы, если не на порядки. Мы лично встречаемсяС одной стороны сильно сокращаются издержки на документирование, общаемся тестирование, случаи решения несуществующих задач, а с клиентамидругой стороны - клиент получает самую свежую функциональность со скоростью горячих пирожков и сразу начинает на этом зарабатывать. Остальные сотрудники Пусть эта функциональность и не обязательно начинают свою работу с изучения предметной областиполная или надежная - это лучше, чем ничего. Мы их обучаем Иногда задача даже может остаться не очень доделанной -главное, что она решает поставленную перед ней конкретную задачу на конкретных данных. Поэтому иногда бывает, что клиент пытается воспользоваться функцией, а она не работает, т.к. писалась для конкретной задачи. С точки зрения клиента это <rspoiler text="глюк">-Исправьте немедленно!!!</rspoiler>, а с нашей - это недофича, которой могло и не быть, и <rspoiler text="никто бы не узнал, что она могла быть">Если, конечно, она не заявлена в перечне функциональности системы: в этом случае мы должны обеспечить корректность ее работы в соответствии с документацией и/или здравым смыслом</rspoiler>.