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