О книге

Книга Никиты Зайцева (в профессиональном сообществе более известного как WildHare) — пример того, как можно систематизировать и упаковать в текстовый формат профессиональный опыт, накопленный за почти 25 лет успешной инженерной практики и участия в больших и по-хорошему «страшных» инженерных проектах.

Разумеется, техническим контекстом является технологический стек 1С, ведь автор всю свою профессиональную жизнь посвятил именно этому уголку IT-вселенной и оперирует теми областями знания, в которых абсолютно уверен и готов отвечать за каждое сказанное слово. Но так как разработка программного обеспечения — это универсальная инженерная дисциплина, то книга повествует о ней в целом, используя технический контекст 1С лишь в качестве иллюстрации, а идеи, принципы и правила, предложенные автором, пригодятся при работе с любым другим технологическим стеком.

Читателю предлагается концепция разработки прикладного программного обеспечения через эффективность процесса на всех стадиях — от работы с ожиданиями и требованиями заказчика до сопровождения и технической поддержки. Все приведенные примеры и рекомендации базируются исключительно на личном практическом опыте автора.

Книга ориентирована в первую очередь на профильных специалистов, то есть людей, занятых в отрасли разработки прикладного программного обеспечения, независимо от текущего профессионального уровня. Публикуемый материал будет одинаково интересен как студентам, так и зрелым профессионалам. Также он может оказаться небесполезным для руководителей любого уровня, имеющих дело с разработкой бизнес-приложений — как в роли подрядчика, так и в роли заказчика.

Суть книги можно кратко сформулировать следующим образом: «Фундаментальные основания профессии». Но если читатель инженер, а не философ, то ему важно не просто «изучать основания», но и уметь применять их, извлекая практическую пользу. А делать это лучше «не спеша, эффективно и правильно» — этот девиз вынесен в название книги.

Желаем приятного и полезного чтения!

Об авторе

Никита Викторович Зайцев (a. k.a. WildHare) — инженер по разработке/эксплуатации автоматизированных систем управления информацией, имеет сертификат 1С «Эксперт по технологическим вопросам крупных внедрений».

За 25 лет профессиональной деятельности прошел путь от программиста-разработчика до технического директора и системного архитектора. Работал в разных прикладных областях — от самых простых до систем «уровня города». Например, участвовал в проекте внедрения УАИС БУ «Облачная бухгалтерия города Москвы», был архитектором и ведущим разработчиком облачной подсистемы «1С:Фреш».

В течение почти всей карьеры сочетал производственные задачи и публицистическую деятельность в области IT: был ведущим популярного технического сайта, вел блог, опубликовал более десятка статей в журнале PC Magazine.

В настоящее время занимается консультированием и преподавательской деятельностью (в том числе в МФТИ и ВШЭ). Ведет технический подкаст «Радио 1С Энтерпрайз» (t.me/radio1c).

От издательства

Ваши замечания, предложения, вопросы отправляйте по адресу comp@piter.com (издательство «Питер», компьютерная редакция).

Мы будем рады узнать ваше мнение!

На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.

Предисловие

В инженерном деле для решения всякой задачи обязательно найдется свой, пусть даже элементарный, метод. Задача в нашем случае весьма простая — кратко и по возможности осмысленно представить книгу будущему читателю.

Когда мы, инженеры, сталкиваемся с чем-то незнакомым и непонятным, то обычно задействуем очень простой метод, который с некоторой долей иронии можно назвать «методом имени Генри Деринджера»1, а именно — задаем себе два элементарных вопроса: а) «Что это?» и б) «Зачем?». То есть очерчиваем область определения и прорабатываем целеполагание. Если определение не вызывает откровенного недоумения, а целеполагание можно признать позитивным, значит, с данной конкретной сущностью можно иметь дело.

Первый вопрос — «Что представляет собой эта книга?». Можно пуститься в пространные рассуждения вроде «конечно, это не учебник в привычном смысле, но все-таки…», но мы постараемся обойтись без попыток определения через отрицание. Несомненно, эта книга является учебником, но только с одной очень важной оговоркой — это учебник для высшей школы.

Если бы перед автором поставили производственную задачу — прочитать академический курс по специальности «Разработка бизнес-приложений на платформе “1С:Предприятие”», первым делом следовало бы написать именно эту книгу, чтобы она легла в основу курса. Звучит слегка самонадеянно, но автору есть с чем сравнивать: те преподаватели, которые в основу обучения закладывали собственные идеи и материалы, действительно были лучшими.

Дело в том, что учебников как таковых существует великое множество, и даже по нашей весьма узкой специальности можно собрать если не библиотеку, то уж как минимум книжную полку. Ни один из учебников не охватывает всю специальность целиком, но зато представляет точку зрения конкретного автора на вопросы, которые автор считает наиболее важными для нашей специальности.

Сопоставляя различные идеи и точки зрения, будущий инженер начинает осваивать профессию, а действующий — расширяет кругозор и повышает свою квалификацию. Собственно, именно этот процесс мы и называем «высшей школой».

Настоящую книгу не следует рассматривать ни как самоучитель программирования, ни как сборник технических рецептов, ни как справочное пособие. Это именно учебник, посредством которого автор попытался донести до аудитории свое понимание специальности «Разработка бизнес-приложений на платформе “1С:Предприятие”», а также поделиться некоторыми обобщениями практического опыта, накопленного за примерно четверть века профессиональной деятельности.

Ответ на второй вопрос — «Зачем?» — представляется очевидным. Зачем читают учебники? Чтобы изучить чужие идеи и опыт, ассимилировать изу­ченное, переработав его в своем сознании с учетом личных обстоятельств, и получить на выходе, во-первых, понимание нюансов профессии, которые до изучения материала представлялись нечеткими и, возможно, зыбкими, и, во-вторых, практическую пользу для своей производственной деятельности.

В чем упомянутая польза заключается? Для инженера, во всяком случае для компьютерного инженера, главной целевой функцией является эффективность (она же производительность труда, она же личная продуктивность, она же много чего еще). Соответственно, и настоящий учебник был изначально ориентирован на улучшение целевой функции, то есть на повышение эффективности. Разумеется, быть эффективным можно только в том случае, когда действие совершается без суеты и спешки, в правильном направлении и с полным пониманием происходящего.

Книга является развернутым ответом на вопрос, который периодически задают автору: «А как тебе удалось достичь такого профессионального уровня?» Краткий ответ дан в названии: «Не спеша, эффективно и правильно». А текст книги расшифровывает этот тезис. Как-то так…

---

Глава 1. Выстраиваем концепцию

В главе 1 начнем рассмотрение темы, как это и положено в инженерном деле, с основ. Если бы нашей темой было программирование, то за основами мы, разумеется, отправились бы в страну математики, возможно даже высшей. Но наша тема — разработка бизнес-приложений, а там, где появляется слово «бизнес», математика переходит в категорию пусть и очень важного, но все-таки инструментария.

Мы, конечно же, не будем рассматривать все теоретические основы бизнеса. На нашей позиции нас более всего интересуют: 1) экономическая модель разработки, точнее, затратная часть этой модели; 2) модель работы на рынке труда ключевых участников процесса разработки, то есть специалиста и его работодателя; 3) те аспекты процесса разработки, которые в современном мире считаются новыми и перспективными (включая влияние на рынок труда). В соответствии с перечисленным выше мы и выстроили содержимое главы.

Главная цель — не просто представить ряд разрозненных соображений и рассуждений на заданную тему, а выстроить их в относительно цельную плотную концепцию. Возможно, полнотой эта концепция похвастаться и не сможет, но совершенно точно должна обладать непротиворечивостью.

Краткий курс политэкономии

К счастью, в современном мире вовсе не обязательно в предисловиях и аннотациях делать реверансы в сторону всесильной и единственно верной теории. Но иногда такой реверанс хочется сделать по доброй воле — из искреннего убеждения, что некая теория, будучи примененной в определенной области нашей с вами деятельности, действительно окажется верной, правильной и почти всесильной.

Наша конкретная область — это разработка бизнес-приложений, что, в свою очередь, является бизнесом. Когда мы говорим «бизнес», мы должны помнить про экономическую теорию (и, понятное дело, наоборот). Экономическая же теория гласит, что для максимально эффективного достижения поставленных целей в условиях ограниченности ресурсов выбор модели поведения в первую очередь обусловливается экономическими факторами. В переводе на русский это означает: «Начиная изучать какой-либо процесс, первым делом сформулируй хотя бы самую простую экономическую модель». Мы не претендуем на полноту формулировки модели, но некоторые ее важные детали постараемся показать, причем наглядно.

Два пути через торфяное болото разработки

Почти как в любом деле, в разработке программного обеспечения можно выделить два принципиально разных подхода (не только на платформе «1С:Предприятие», это универсальный принцип).

Путь 1. Быстро и криво

Простой подход — сделать быстро, затратив минимум ресурсов. Пускай будет слегка криво, пускай не будут учтены нюансы эксплуатации, пускай кое-где вылезут ошибки. Зато заработает прямо сразу (как мы всегда надеемся). Ну а потом исправим ошибки, напишем документацию, отработаем замечания заказчика и сделаем еще десяток добрых и полезных дел.

У такого подхода есть одно серьезное преимущество. Если расположение звезд окажется удачным, а разработчик более или менее опытным — что-то действительно заработает «прямо сразу». И какое-то время это «что-то» будет функционировать.

Но есть и недостатки, не менее серьезные. Во-первых, результат разработки по принципу «быстро и криво» далеко не всегда начинает работать «прямо сразу». Практика показывает, что частенько запуск проходит в строгом соответствии со старой шуткой о промышленном шпионаже: «после сборки тщательно обработать напильником».

Во-вторых, в процессе разработки нас ожидают типичные ловушки и, как результат, разработка практически со 100%-ной вероятностью имеет хотя бы один из перечисленных ниже изъянов.

• Неустойчивость к входным данным («Очень странно, у меня же все загружалось!»). При написании кода использовались самые примитивные примеры, а в реальных данных заказчика оказалась закопана добрая дюжина грабель с прочными дубовыми черенками.

• Несоответствие техническому заданию и ожиданиям заказчика в целом («Мы думали, что нужно просто создать и записать документы, а чтобы при повторной загрузке изменять ранее созданные вроде бы речи не было!»). Прямое следствие тактики «Код пишется параллельно чтению технического задания». Задание читается по диагонали, ведь писать код значительно интереснее.

• Неполнота реализации требуемых функций («Протоколирование мы пока еще не сделали, и в отчете пока только две колонки без детализации. Мы это потом доделаем, но данные загружать можно уже сейчас»). Заказчику предлагается что-то вроде легкового автомобиля без стекол и кресел — можно же пока и табуретку поставить. Используя инженерную смекалку, всегда можно найти временное решение. Беда (для заказчика) в том, что вре́менные решения с течением времени получают статус постоянных, раз уж проверку временем выдержали.

• Наличие элементарных ошибок. Под «элементарными» здесь понимаются такие ошибки, которые возникают в основном потоке событий приложения, причем с валидными входными данными («Здесь пока не обращайте внимания, просто нажмите “Отмена”, а дальше сначала нажмите “Обновить”, потом снимите и сразу поставьте обратно эту галочку, а потом уже “Сформировать”», — представитель заказчика лихорадочно записывает на бумажку). Работа с установкой «Мы просто пишем код», к сожалению, не предполагает затрат труда и времени на альфа-тестирование хотя бы основного потока событий и уж тем более альтернативных потоков.

• Низкое качество кода с точки зрения дальнейшего сопровождения и развития функциональности (через месяц после запуска: «Нет, эту функцию добавить не получится, тут нужно будет почти все полностью переписать». — «Почему?» — «Какие сроки были поставлены, вы помните? Поэтому и переписать!» Через шесть месяцев от представителя другой команды специалистов: «Кто же это вам такую красоту написал? Руки бы оторвать! Тут нужно все переделать с нуля!»).

Почему так?

«Ибо дело, свершенное в спешке, никогда не бывает свершено наилучшим образом» (Дэвид Эддингс, «Сияющая цитадель»2).

Памятка руководителю. Распознать, что разработка велась по принципу «быстро и криво», можно по внешним родовым признакам, даже не заглядывая в код. Вот некоторые из них:

1) не менее 50 % трудозатрат — трудозатраты на отладку;

2) отсутствие внятных пользовательских инструкций;

3) большое (больше двух) количество итераций «сдали результат — попробовали эксплуатировать — что-то не работает — вернули на доработку»;

4) наличие ошибок, которые обнаруживаются вторым-третьим кликом;

5) наличие замечаний типа «Эта ошибка уже была в одной из предыдущих версий, но ее же исправляли?!»

Нельзя сказать, что подход «быстро и криво» является абсолютным злом. Существует несколько классов задач, где такой подход действительно позволяет значительно сэкономить трудовые и временны́е ресурсы.

• Быстрое прототипирование. Проверить гипотезу, понять принцип действия какого-то механизма платформы, попробовать сопряжение с каким-то сторонним API и т.п. При этом нужно четко понимать, что «быстрый прототип» делается на выброс, это даже не временное решение, а просто пробник.

• Ликвидация аварий. При тушении пожара хороши любые средства, и когда система собирается падать (или уже падает), вопросов, насколько грамотно, изящно и эффективно написан «подпирающий» код, не возникает в принципе. Только нужно потом не забыть заменить костыли добротной инженерной конструкцией (см. выше про «вре́менные решения»).

• Одноразовые инструменты «для себя». Когда требуется написать, например, какой-то крохотный корректировщик данных вида «использовал и выбросил», абсолютно незачем забивать себе голову «альтернативными потоками событий», «снижением издержек на сопровождение» или другими подобными высокими соображениями.

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

Путь 2. Не спеша, эффективно и правильно

Подход посложнее — не приступать к написанию кода раньше времени, не пытаться сэкономить на ресурсах лишний грошик. Разработка даже самого простого механизма, самой элементарной, казалось бы, функции выстраивается в пять стадий.

1. Анализ. Изучение задачи, изучение текущего положения, выявление противоречий, уточнение неочевидных мест, допущений и ограничений.

2. Проектирование. Разработка «на бумаге». Принятие основных проектных решений (при необходимости с проверкой на быстром прототипе).

3. Кодирование. Собственно написание и отладка кода. Честно говоря, это не самое захватывающее занятие — если все продумано и правильно спроектировано, код является очевидным, и очень жаль, что сам себя он писать пока еще не способен.

4. Проверка. Прежде чем передавать какую-то разработку (даже на тести­рование), разработчик обязан самостоятельно проверить, по крайней мере, основной поток событий и поток наиболее очевидных ошибок.

5. Документирование. Написание инструкций по развертыванию, эксплуатации, разрешению известных проблем. Фиксация «на бумаге» наиболее важных и/или сложных проектных решений.

Кажется слегка громоздким, верно? Но все дело в масштабировании. Если мы пишем простенькую обработку, стадии анализа и проектирования можно пройти за десять минут, не написав ни слова, а инструкция будет представлять собой короткую надпись на форме. Важно, чтобы любая разработка проходила все пять стадий, точно в указанном порядке.

У разработки по принципу «не спеша, эффективно и правильно», разумеется, тоже имеются недостатки.

• От разработчика требуется не только мастерство в написании кода, но еще и способности к абстрактному мышлению.

• Также разработчику нужно понимать, что такое бизнес-анализ, и хотя бы мало-мальски уметь мысленно поставить себя на позицию пользователя. Никакой «работы по четкому ТЗ» здесь не будет, любое ТЗ придется потрошить в поисках противоречий и недосказанностей.

• Прямо завтра ничего не заработает. Как говорится, прежде чем поехать, какое-то время будем запрягать.

• Эффективная и вдумчивая разработка кажется значительно дороже быстрой и бездумной. Причем так кажется не какому-то воображаемому критику, а собственному руководству и представителям заказчика.

Преимущества же работы по принципу «не спеша, эффективно и правильно» в том, что это позволяет исключить практически все недостатки разработки «быстро и криво»:

• система устойчива к любым входным данным;

• результат соответствует ожиданиям заказчика;

• код содержит минимальное количество ошибок (если и встречаются, то некритические);

• разработка вполне пригодна для сопровождения, а дальнейшее развитие не потребует переписывать все заново.

Смертельная схватка цены и качества

Казалось бы, вопрос только в цене, которую мы (и наш заказчик) готовы заплатить за качество. Достаточно выбрать метод реализации проекта: либо «быстро, криво, дешево», либо «медленно, качественно, дорого». В некоторых случаях упростить выбор заказчику может картинка-мотиватор (рис. 1.1).

Рис. 1.1. Памятка заказчику

Но, правда, есть нюансы.

Закон сохранения стоимости

Дело в том, что любая задача разработки по своей сути является чьей-то проблемой. На «создание проблемы» был затрачен определенный объем труда. Для полноценного решения задачи потребуется такой же объем труда и ни одним нормо-часом меньше.

Здесь работает брат-близнец закона сохранения массы имени Ломоносова и Лавуазье (хотя кто только этот закон не формулировал: в европейской истории среди первых был Эмпедокл, а в мировой — наверняка еще на стенах пещер царапали. Наиболее же остроумную трактовку фундаментального закона, относящуюся к соотношению числа компетентных и некомпетентных работников в компаниях, предложил Скотт Адамс в своей замечательной книге «Принцип Дилберта»3).

Если поступит установка «сэкономить на кодировании», то разработку, скорее всего, придется вести поспешно, жертвуя качеством. Да, это будет дешево и заказчик заплатит только часть реальной стоимости, но и взамен получит лишь частичное решение своей проблемы — как тот посетитель трактира из старой сказки, которому пришлось довольствоваться ароматом блюд вместо пищи, потому что трактирщику смог предложить лишь звон монет вместо денег.

То, что результат неполный, можно определить по самым разным признакам. Например:  

• действия, которые могли быть автоматизированы при полноценной разработке, автоматизированы не все. Следствие — пользователи затрачивают лишнее время на ручные операции;

• не реализована проверка входных данных, нет защиты от неправильных действий пользователей. Следствие — множественные ошибки ввода;

• отсутствуют средства протоколирования. Следствие — невозможно разобраться в причинах некорректного поведения системы («Это пользователь ввел что-то не так или система посчитала неправильно? А может, звезды не так стояли?»); для групповых операций невозможно «откатить обратно» или «запустить заново с места сбоя»;

• добавление новой функции и/или модернизация любой существующей требует затрат, сопоставимых с исходной разработкой;

• большое число ошибок в коде приводит к частым сбоям и простоям (а это тоже затраты заказчика, пускай и косвенные) —

и так далее.

В общем, если на стадии разработки был применен принцип «быстро и криво», то на стадии эксплуатации это закономерно приведет к паттерну «криво, медленно и печально».

Это как экономить на туалетной бумаге, если, конечно, такое сравнение будет уместным. «Экономная» хозяйка уверена, что качественная четырехслойная бумага ей не по карману. Но она не задумывается, что самую дешевую бумагу, которая расползается прямо в руках, придется на американский манер сворачивать вшестеро. По деньгам выйдет примерно столько же, а вот по удобству — да сами попробуйте.

Парадокс убыточного удешевления

Самое интересное заключается в том, что закон сохранения стоимости имеет только нижнюю планку и в окончательной редакции «для реальной жизни» выглядит следующим образом.

Разработка по принципу «быстро и криво» не может обойтись дешевле, чем разработка по принципу «не спеша, эффективно и правильно». А если проект будет реализован криво, то такая разработка может обойтись и значительно дороже.

Это важный момент, и мы разберем его подробно на реальном примере из практики автора. Без имен и названий, разумеется (хотя действующие лица, если текст попадется им в руки, без сомнения, себя узнают). Масштаб немного изменен для наглядности, но в первую очередь еще и потому, что NDA4 нужно уважать.

Место действия — масштабный амбициозный проект по разработке и запуску большой и по-хорошему «страшной» информационной системы. Один из этапов проекта — перенос (миграция) почти тысячи локальных систем со всеми данными «с земли» в единый облачный программный комплекс. «Наземные» системы относились к нескольким разным типам, из которых только одна была реализована на платформе 1С. Предельно сжатые сроки, чудовищные штрафные санкции за срыв графика, кривые локальные базы, активный саботаж на местах — все как мы любим.

Инструментарий миграции заказали стороннему подрядчику, своих ресурсов на разработку не было. Но совершили серьезную ошибку — дали подрядчику полную свободу действий. Никто не курировал разработку, никто не проводил аудит промежуточных результатов. Ну а подрядчик подошел к делу творчески, в полном соответствии с поговоркой про сберегающую рубль копеечку.

Концептуальная часть инженерного решения была вполне грамотной. Если нужно свести данные из пяти разнородных систем в одну, представлялось разумным разработать некий промежуточный формат, перегонять локальные данные в унифицированные файлы, а затем уже загружать в единую систему. Прекрасное было решение, без шуток. Но техническое воплощение этой концепции в личном рейтинге автора в номинации «Быстро и криво» и по сию пору занимает безоговорочное первое место. Объясню почему.

Во-первых, в качестве формата для промежуточных данных был выбран MS Excel строго определенной версии — формат, не обеспечивавший даже элементарного «прочитано будет точно то же значение, что и было записано». Очень сложно объяснить ответственным за инфраструктуру, что на серверах нужно установить MS Office такой-то, чтобы можно было вызывать Excel через COM-соединение, притом что ранее была поставлена задача перевести часть серверного парка на Linux.

Почему же был выбран самый неудобный формат? Почему не JSON, не XML, даже не xBase? Подрядчик, разумеется, настоящую причину не озвучил. А дело было в том, что у «программиста» имелись некие готовые механизмы работы с файлами Excel. И чтобы не писать код заново (а еще, не дай бог, не тратить время на изучение приемов работы с JSON/XML), проще эксгумировать старый код и как-нибудь натянуть его на задачу. Экономия трудозатрат? Ударная скорость разработки? Вне всякого сомнения!

Во-вторых, было принято техническое решение класса epic — не изобретать новые механизмы загрузки данных, а слегка допилить уже встроенную в типовое решение механику перехода с предыдущей редакции (здесь следует передать горячий привет «правилам конвертации», и мы не упустим такого случая: «Привет, правила! Идущий К Ручью С Камнем На Шее приветствует вас!»). Да, при таком решении весь программный код работы с данными (начиная с чтения *.xlsx) придется утрамбовать в некий «дополнительный обработчик», то есть в обычный текстовый файл. Да, этот код будет исполняться через оператор Выполнить и его невозможно будет даже пройти отладчиком. Ну и что, отладка — для тру́сов! А нашим крутым «программистам» достаточно лишь пристального взгляда, чтобы найти все ошибки, даже в спагетти-коде в полторы тысячи строк.

И в-третьих, на стороне подрядчика никому не пришло в голову, что промышленная загрузка сотен и сотен файлов в единую систему «немножечко» отличается от загрузки единичного файла в настольную, по сути, информационную базу. Ведь нет гарантии, что локальные данные чужеродной системы с первого раза совпадут с парадигмой целевой конфигурации и их не придется загружать повторно. Также не подумали, что число ручных операций и процедур клиент-серверного взаимодействия нужно минимизировать. Не реализовали «страшную» процедуру верификации входных данных и пошли по сценарию «начали загружать, обнаружили ошибку в данных, запаниковали, бросили работу».

Казалось бы, лучшие практики не представляют собой секрета. В самом простом варианте:

• загрузчик на стороне кластера слушает некую директорию;

• файлы для загрузки подкладываются туда по мере поступления;

• каждый файл содержит аннотацию (что это, откуда, куда загрузить, кого уведомить);

• загрузчик держит какое-то число потоков обработки (в рабочее время поменьше, в нерабочее — побольше), отслеживает результаты, ведет протоколы и рассылает уведомления.

Да, такой загрузчик еще нужно написать и отладить. Но зачем? Все уже было написано. Быстрая разработка предполагает, что есть готовый код — его нужно использовать по максимуму.

И пусть специалисты, занятые на процессах миграции данных, вручную запускают клиентское приложение: «Начальная загрузка, три страницы мастера (настройки всегда одинаковы), выбрать файл и ждать, когда и чем закончится». Сколько ждать — десять минут, час или пять? — никакого намека на «обработано примерно N %». А что будет, если десять биороботов запустят по 7–8 потоков загрузки каждый, причем в рабочее время и одновременно? На инфраструктуру ляжет нагрузка 80 сеансов, каждый из которых пишет и проводит сотни (а то и тысячи) документов без всяких пауз, вкупе с обычной нагрузкой от пользователей единой системы. Но выдержит ли? Можно даже делать ставки (только, понятное дело, админов к тотализатору не допускать!).

Если загрузка прошла успешно, нужно через клиентское приложение зайти в программу и вручную пройти 22 (это не шутка, ровно 22!) страницы «Мастера настройки». Притом что значения настроек всегда одинаковые, обработку для пакетной установки не сделали. Это долго и сложно, в «Мастере настройки» пришлось бы повозиться с установкой констант, а еще пришлось бы изучить бизнес-логику. Зачем писать лишний код, если функция и так доступна? Незачем.

Вот теперь давайте посчитаем трудозатраты на разработку и проверку самого простого пакетного загрузчика —хотя бы в первом приближении, по принципу «на два лаптя правее солнышка». Пусть будет десять рабочих дней (80 часов). Допустим, весь проект рассчитан на год, и техник, который будет вести и контролировать процесс, потребуется примерно на два часа в день. На 2023 год (где 247 рабочих дней) получается: 80 + 247 × 2 = 574 часа.

Фронт работ в полях: примерно тысяча локальных систем. Надо учитывать, что редко какая миграция удается с первого раза, и не только по техническим причинам (напоминаю, в нашем примере имел место «саботаж на местах»). Допустим, что показатель «число загрузок на систему» составляет 2,5 раза (хотя, по правде, число занижено). Предположим, что время, требуемое технику на одну операцию загрузки без учета нештатных ситуаций, — 30 минут. Примем, что разработка инфраструктурного слоя для загрузчика данных не была реализована — 0 часов. Считаем: 0 + 1000 × 2,5 × 30/60 = ~1250 часов. И это самая нижняя планка.

Понятно, что ставка квалифицированного разработчика несколько выше ставки квалифицированного техника. Но в любом случае себестоимость быстрого и предполагаемо дешевого решения в итоге для подрядчика проекта окажется вдвое выше себестоимости медленного, хорошо реализованного, но изначально дорогого.

Теперь представим, что показатель «число загрузок на одну локальную систему» составит хотя бы 3,5 раза (например, сложная предметная область, множественные ошибки и недоработки в инструментах конвертации, массовое саботирование процесса выверки данных, необоснованные требования повторной миграции и так далее). И представим, что средняя операция загрузки потребует не 30, а 45 минут рабочего времени техника (учтем ситуации, когда «загрузка упала, нужно заново»). Получается 1000 × 3,5 × 45/60 = 2625 часов.

А если предстоит миграция 1000 локальных систем только в первой очереди проекта, еще 700 во второй очереди и еще 500 в третьей? Придется как минимум еще разок удвоить стоимость.

Домашнее задание читателю: вычислите, сколько мы в итоге сэкономили при быстрой разработке, повторном использовании ранее написанного кода и максимальном задействовании типовых механизмов. Ответ лучше сразу в рублях.

Парадокс психологии руководителя

Тем, кто работает в отрасли достаточно долго, из практики известно, что при прочих равных руководители всех уровней из вариантов: 1) «быстро и криво» и 2) «не спеша, эффективно и правильно» — почти всегда выбирают первый. Почему?

Все просто. Здесь срабатывают сразу две ментальные ловушки: «выгодная цена» и «все будет хорошо».

Ловушка выгодной цены прекрасно известна всякому, кто хотя бы раз в месяц бывает в супермаркетах. Именно там попавшие в ловушку граждане-экономы покупают годовой запас самой дрянной туалетной бумаги за крайне выгодную цену 19 рублей. Хотя четырехслойную бумагу с ароматом ромашки за 119 руб­лей им пришлось бы покупать куда реже, затраты на год остались бы на том же уровне, а уровень личного комфорта получился бы на два порядка выше.

Вот и руководитель, когда смотрит в платежную ведомость или в бюджет проекта, считает очень выгодным вычеркнуть из числа 119 первый знак слева.

Ловушка «все будет хорошо», как и ловушка выгодной цены, базируется на фатальных дефектах человеческой психики. «Выгодная цена» эксплуатирует жадность, а «все будет хорошо» — страх и лень. Мы не любим, когда случается что-то плохое, нам это неприятно. Думать о неприятном заранее — живот заболит. Да и незачем думать, ну вот что может случиться? Все будет хорошо, этой мысли достаточно.

Да, в прошлый раз тоже делали быстро и криво, в итоге проект провалился в глухой убыток. Но там были грубые ошибки — в следующем проекте мы их обязательно учтем. Тогда специалисты-новички еще не освоились, а сейчас они уже опытные ветераны. А в позапрошлый раз мы даже получили неплохую прибыль. Правда, это потому, что у заказчика сменился директор по ИТ и нашу разработку они не проверяли, а просто выбросили. Но мы-то уверены, что все было бы хорошо.

Если отжать из болтовни сухой остаток, получится примерно такая формулировка.

Отличие профессионального руководителя от дилетанта в том, что первый испытывает настоятельную потребность каждодневно на практике применять методику управления рисками, а второй лишь теоретически рассуждает о ней.

Читатель без труда может провести простейший тест на профпригодность руководителя любого звена, от тимлида до директора. Нужно всего лишь ненавязчиво поинтересоваться отношением товарища руководителя к работе граждан Тома Демарко и Тимоти Листера, изданной под названием «Вальсируя с медведями: управление рисками в проектах по разработке программного обеспечения»5. Если ответом будет изумленное «Что?» поверх стопки покетбуков из серии «Очередной учебник менеджмента, или Как повысить продуктивность и креативность работы в команде через геймификацию, хакатоны и гибкие методики», диагноз можно поставить мгновенно. Неутешительный, надо признать, диагноз.

Парадокс заключается в том, что в быту руководитель проявляет осторожность и осмотрительность, прекрасно умеет взвесить и оценить риски, управляет этими рисками, причем успешно. Если неопрятный человек подозрительной наружности в безлюдном переулке предложит купить золотую монету по цене пары фугасов бормотухи — вряд ли товарищ руководитель скажет себе: «Все будет хорошо» — и полезет в карман за бумажником.

Но почему-то в рабочих вопросах такой подход у многих руководителей считается нормальным. Когда «программист» Петр уверяет, что легко «запилит этот трактор» за выходные («Возьму старые наработки, уже решал такие задачи!»), товарищ руководитель мысленно вычеркивает левый знак из цифры 119, светлеет лицом и дает «трактористу» Петру зеленый свет. Доставать бумажник из корпоративного кармана (не говоря о карманах заказчиков) почему-то гораздо легче, чем из собственного.

Это не хорошо и не плохо (для инженера вообще не бывает «хорошо» или «плохо»), это просто медицинский факт, с которым нужно считаться. Но не нужно мириться! Руководитель, как любой человек, в хорошие дни поддается воспитанию, а в плохие — техникам манипулирования. Развивать тему подробно мы не будем, все же это предмет совсем другой книги. Заметим только, что разработчик, который не умеет в нужный момент сказать руководителю нужные слова, редко добивается больших профессиональных успехов.

И еще одна важная деталь. Пустые споры с руководством «за качество» не приводят ни к чему хорошему. Любой такой разговор требует тщательной подготовки. Нужно заранее:

• продумать план разговора;

• заготовить досье;

• создать точный перечень проблем и потерь — какие и когда были;

• провести расчеты;

• сформулировать аргументы.

На всякий случай: «Надоело гопокодить!» проходит по ведомству детского лепета, а не аргументов (расшифровка термина «гопокод» приведена в разделе «Темная сторона Силы» главы 2). Руководителя нельзя убедить эмоциями, а вот суммами — можно хотя бы попытаться.

Парадоксы эффективной разработки

Нельзя не согласиться, что разрабатывать программное обеспечение не спеша, эффективно и правильно — дело непростое. Далее в книге мы подробно разберем конкретные практические приемы и реальные примеры, а пока достаточно двух слов: будет непросто.

Приведем аналогию из мира прекрасного, например шахматы. Дилетант знает, как ходят фигуры, знает некоторые правила, возможно, даже знает, как и для чего пользоваться шахматными часами. Но играет по наитию — как мироздание на душу положит: «Если достались белые, сходим e2 — e4, ввяжемся в бой, а там посмотрим». Профессиональный же игрок не просто знает физический смысл понятия «гамбит», но, к примеру, может внятно объяснить тактический прием под названием «гамбит Геринга» и применить его при разыгрывании шотландской партии. А это, уж поверьте, будет непросто.

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

Так в чем же парадоксы? Формула вроде бы очень простая: «“долго, дорого, занудно” равняется “качественно, надежно, удобно”».

Первый парадокс («вершки») в том, что если вместо «занудно» подставить в формулу «эффективно», то «долго» превращается в «не спеша», а «дорого» — в «правильно». Спутать занудство с эффективностью по внешним признакам очень просто. «Вот же зануда, — часто говорят про автора, — все-то у него по полочкам, все на своем месте». Элементарный пример: на соседних столах две рабочие станции, на каждой есть локальная информационная база, обе базы подключены к одному хранилищу.

У коллеги база расположена вот здесь:

c:\Работа\Базы\хрень-9

У автора хранение организовано иначе:

c:\home\v8-stuff\infobases\dev\sm\jt-3741\storage-common

что означает: «домашний каталог\материалы по восьмой платформе\информационные базы\разработка\задача описана в JIRA под номером 3741\общее хранилище». Это занудство или эффективность? Попробуйте угадать.

Есть и второй парадокс эффективной разработки («корешки»). Эффективная разработка действительно стоит дороже, если учитывать только прямые затраты. Если же включить в бюджет затраты на развертывание, запуск, обучение, сопровождение и развитие, последует довольно неожиданный вывод: дорогой в разработке проект в итоге оказывается существенно дешевле проекта с недорогой и быстрой разработкой — как для заказчика, так и для подрядчика.

И наконец, самое парадоксальное. Эффективная разработка требует от специалиста аккуратности, развитого абстрактного мышления, высокой квалификации, знания множества отраслевых паттернов, умения изобретать инженерные решения и так далее. Но на практике занудная эффективная разработка поглощает существенно меньший объем труда и времени, чем быстрая и веселая. При этом эффективный специалист зарабатывает существенно больше денег, чем его быстрые коллеги. Вы не поверите, но иногда даже кратно больше (автору такие феномены известны).

Домашнее задание читателю. Грамотно с точки зрения предпочтений присвойте количественные характеристики «меньше» и «больше»: а) затратам рабочего времени; б) денежным знакам, имеющим хождение в стране проживания читателя.

Кофе-пауза #1. Орден Бани для ИТ

Сперва в качестве эпиграфа повторим слова замечательного американского писателя-фантаста в жанре фэнтези Дэвида Эддингса:

«Ибо дело, свершенное в спешке, никогда не бывает свершено наилучшим образом».

А теперь давайте придумаем рыцарский орден для тех специалистов по ИТ, которые выполняют свою работу с торопливостью, достойной человека, который в бане голышом изо всех сил спешит в парилку. Так и назовем: Почетнейший орден Бани для ИТ (The Most Honourable Order of the Bath for IT). Надеюсь, Георг I6 простит автору этот легкий плагиат.

Орденский знак отливается из легких алюминиевых сплавов. Помните, были такие смешные ложки в заводских и школьных столовых? Визуально знак представляет собой греческую букву Ω.

У ордена две степени: «Легкое поведение в сауне» и «Реальная паровая баня». Посвящение кандидатов проводится строго по канону короля Георга:

• ночное бдение (над важной и срочной задачей);

• молитва («Господь всемогущий, пожалуйста, сделай так, чтобы эта хрень запустилась»);

• аскеза (никаких печенек до утра, и сахар закончился);

• макание лицом в ледяную воду в финале (осознание разрушительных последствий своей деятельности — руководители и старшие товарищи помогут).

Примеры? Сколько угодно. Вот на выбор три кавалера (все истории, разумеется, подлинные, ничего не выдумано).

Мистер Синий. Служил техником на очень большом проекте. Очень торопился завершить рутинную, скучную, но крайне важную задачу. Работа велась через RDP-сессию, и с последним выдохом «Ну наконец-то!» гражданин последовательно нажал на «Пуск» и на «Завершить работу». Поздний вечер пятницы, все админы давно в кабаке, номера их телефонов — коммерческая тайна заказчика. Коллегам, которые на этом же сервере решали свои не менее важные задачи или предполагали заняться ими в субботу, было крайне весело. Орден Бани для ИТ II степени.

Мистер Розовый. Служил в коммерческой конторе на должности DBA в те «лохматые» годы, когда в ходу был еще MS SQL Server 6.5, занимался мелкой подстройкой параметров производительности. Где-то вычитал, что можно поместить часть tempdb прямо в RAM, и так загорелся этой идеей, что в спешке не разобрался в метрике. Задал емкость в Kb, а надо было в Mb. После перезапуска от СУБД осталось одно только сообщение об ошибке. В техническом английском гражданин был не силен, так что ему показалось, что сервер сказал что-то вроде «Ха-ха, тупое ты <много слов 18+>!»). Результат: деятельность предприятия парализована на целый рабочий день, при лихорадочной попытке переустановки испорчена база данных, крайний бэкап был двое суток назад. И всего-то пять поспешных тюков по клавиатуре! Орден Бани для ИТ I степени.

Мистер Зеленоватый. Служил директором по ИТ на большом заводе. Должность громкая, но, по сути, просто совмещал обязанности главного админа и главного программиста. Очень торопился завершить переезд инфраструктуры на новое железо, даже остался в серверной на ночь. Чтобы не потерять аппаратный ключ (запасного нет), положил в самое надежное место, в карман брюк. А рано утром сел в поезд и уехал в отпуск в какую-то тмутаракань. Разумеется, с аппаратным ключом в кармане. Как вы думаете, насколько просто достать ключ на 500 лицензий хмурым утром вторника, будучи рядовым админом на глухом провинциальном заводе, откуда до ближайшего дистрибьютора пилить две сотни верст? Полный кавалер ордена Бани для ИТ. Ордена предписано носить на тех самых брюках, но не на кармане.

Читатель скажет: «Админы такие админы, но при чем здесь разработка?» Нет повода волноваться, уважаемый читатель, дойдет очередь и до разработчиков.

Собеседование в трех гримасах

Почему-то на собеседовании принято задавать множество различных и зачастую глупых вопросов. Топ-3 HR-беспомощности, по версии автора, выглядит следующим образом:

1. «Почему мы должны нанять именно вас?»;

2. «Кем вы себя видите в нашей компании через пять лет?»;

3. «Какими задачами вам интересно было бы заниматься?».

Плохие вопросы — это тема совсем другой книги. Если же требуется оценить профпригодность специалиста не на техническом, а на концептуальном уровне, это тоже можно сделать с помощью трех вопросов. Правда, есть вероятность, что какой-то из ответов вызовет на лице проводящего интервью гримасу, которую опытный соискатель мгновенно расшифрует как «Спасибо, мы вам обязательно позвоним».

Вопрос 1. Ремесло или творчество?

В нашем сообществе отчего-то бытует мнение, что «программист» — это творческая профессия. Нет ничего более далекого от истины. Внимательный читатель уже заметил, что в этой книге речь идет только о разработчиках, а слово «программист» если и встречается, то заключено в кавычки. Именно так: никаких «программистов» во вселенной разработки на стеке технологий 1С не существует и существовать не может.

Никакие мы не программисты. Мы разработчики прикладного программного обеспечения.

Ну а кто же тогда настоящий программист? Ну, например, парень, который развлечения ради может взять голое железо и написать на Асме Форт, а на Форте Лисп — за субботний вечер «под бутылочку доброго “Сингл Молт”» и теплый ламповый джаз. Автор в свое время был знаком с несколькими такими парнями. Да, они могут писать и на 1Cv8, но это не превращает их в «1С-программистов».

Не поленимся почтить формальную логику и запишем очередную гранитную формулировку.

Программист запросто может заниматься разработкой программных продуктов, но разработчик программных продуктов вовсе не обязательно является программистом.

Это действительно очень важный момент. Для эффективной разработки прежде всего нужно, чтобы над головой не сиял нимб и корона с надписью «Самый умный парень на деревне» была подогнана по размеру черепной коробки. Если кандидат на позицию старшего или ведущего разработчика на вопрос «Ремесло или творчество?» ответит, мол, несомненно, его профессия творческая, — собеседование можно считать завершенным.

Никакого творчества в разработке программного обеспечения нет, и взяться там ему неоткуда.

Разработка — это безусловное ремесло.

Суть процесса разработки заключается в том, чтобы:

1) распознать задачу и декомпозировать до необходимого уровня;

2) выбрать из набора уже известных паттернов нужные и временно забыть про все остальные;

3) недостающие паттерны найти, изучить и включить в свою ментальную биб­лиотеку;

4) несуществующие, но необходимые паттерны изобрести, запомнить и поделиться с коллегами;

5) разработать необходимое программное обеспечение, применяя правильные паттерны к отдельным компонентам задачи.

«Изобрести», а не «сотворить», понимаете?! Хайрем Максим7 и Дуглас Энгельбарт8 (эрудированный читатель может подставить имена своих любимых инженеров) не были творческими людьми, они не творили, а изобретали и конструировали. Даже великий Леонардо, когда от мольберта переходил на тогдашний аналог кульмана, временно переставал быть человеком творческой профессии.

В слове «ремесленник» нет ничего плохого и унизительного, это гордое слово. Быть настоящим ремесленником — значит быть мастером своего ремесла, мастером своего дела. А вот граждан, у которых над головой сияет «нимб творчества», автор, как бы это помягче, опасается видеть в непосредственной близости от своих рабочих задач. Если ремесленнику с творцами и по пути, то разве что по пути в кабак или чайный домик.

«Вы человек творческой профессии? Спасибо, мы вам обязательно позвоним».

Вопрос 2. Олимпиада или производство?

Очевидно, что для любого сколько-нибудь вменяемого разработчика яркая олимпийская соревновательная деятельность интереснее и привлекательнее скучного производства с его станками, гудками и планами выпуска. Но у этого вопроса есть второе дно.

Олимпийский (назовем его так) стиль разработки предполагает, что целью является решение конкретной задачи, и только ее. И решение должно быть рекордным — самым быстрым, изящным, остроумным, компактным, самым <подставьте любое слово>. Ни о каком сопровождении и развитии речи даже близко нет. Поэтому обычный линейный специалист не сможет понять, почему код, написанный олимпийским небожителем, вообще работает. В таком коде страшно тронуть даже комментарий (а он может состоять из одного слова — три буквы, средняя «у», не «душ»).

Почему же для эффективной разработки олимпийский стиль есть безусловное зло и беда (а это именно так)? Попробуем призвать на помощь добрую фею из мира прекрасного — Аналогию. Три кейса из военной истории на выбор.

1. Беспосадочный перелет экипажа АНТ-25 из Москвы до Ванкувера через Северный полюс под командованием Валерия Чкалова. Тысяча девятьсот тридцать седьмой год. Авиация Красной армии наглядно показала американским коллегам, что сможет отправлять бомбардировщики в любую точку на карте мира.

2. Рейд американских базовых бомбардировщиков B-25B на Токио под командованием подполковника Джеймса Дуллитла. Тысяча девятьсот сорок второй год. Задействовав авианосец «Хорнет», американская армия наглядно показала японским «коллегам», что, даже лишившись всех баз в Тихом океане, можно достать до Токио.

3. Переход американского низкобортного башенного броненосца «Миантаномо» через Атлантический океан в Европу (миссию возглавлял военно-морской министр США Густав Ваза Фокс). Тысяча восемьсот шестьдесят шестой год. Американский флот наглядно показал «коллегам» из Англии и Франции, что за рекордные 11 дней сможет подогнать пару-тройку своих монстров прямо в гавань Плимута.

В каждом из этих кейсов была успешно решена задача не просто рекордная, а героическая, без всяких шуток. Задача класса unreal. Есть в этих примерах и другие общие черты.

• Для выполнения задачи требовалась длительная, масштабная и очень дорогая подготовка.

• Используемая техника либо вообще не была серийной, либо была модифицирована под задачу и работала далеко не штатно.

• Целью было — повысить моральный дух собственных войск и оказать моральное давление на противника.

• Никакой практической пользы от выполнения рекордных задач не последовало.

• Попыток повторения задачи именно в таком виде больше не предпринималось, каждая из представленных задач была решена в единственном экземпляре.

Что характерно, каждый рейд сопровождался запредельным риском и закончился успехом благодаря чудесам природы и человеческой выносливости. Не случись тех чудес, и первые, и вторые, и третьи закончили бы свой олимпийский путь на океанском дне, а вместо героического триумфа случился бы стыд и позор, а враги по такому прекрасному поводу закатили бы праздничный банкет.

Вот поэтому рекорды хороши только на своем месте и в свое время. Для эффективной разработки программных продуктов олимпийский стиль не годится уже хотя бы потому, что результаты не получится тиражировать. Даже если HR-служба сможет найти на рынке труда других олимпийцев.

Небольшой дисклеймер. Автор вовсе не против спортивного программирования как части олимпийского движения. Соревнования по программированию прежде всего ориентированы на вовлечение молодых людей в нашу профессию, нашу индустрию. Но важно не забывать, что первая фраза мастера, обращенная к новому подмастерью, на любом языке звучит так:

«Забудь все, чему тебя учили раньше. Здесь ты будешь учиться работать».

Этот совет верен, даже когда у подмастерья на рабочем столе красуется золотая олимпийская медаль.

По сравнению с олимпийским, производственный подход к разработке должен казаться скучным. В нем нет (или почти нет) места героизму, рекордам и овациям. Даже когда на производстве совершается нечто героическое, кроме ближайших коллег, никто и никогда об этом не узнает и даже простого «спасибо» ожидать не стоит. Но не будем грустить по этому поводу, наше ремесло устроено по крайне простому принципу:

«Мы работаем за деньги, решаем технические проблемы заказчика и со­здаем для него материальные блага».

Давайте попробуем перечислить родовые признаки эффективной разработки в производстве.

1. Целью производственной деятельности не является решение каких-либо задач только ради их решения:

• основой целью в коммерческом производстве является создание добавленной стоимости через изготовление продукции и/или оказание услуг;

• в некоммерческом производстве (если такое вообще бывает) цель описана в соответствующем положении устава.

2. Любая задача по разработке программного обеспечения решается с прицелом на дальнейшее развитие, дополнительную продажу, возможность тиражирования.

3. При разработке программного продукта уже на этапе эскизного проектирования сразу принимается во внимание фактор эксплуатации:

• возможность сопровождения даже специалистами не очень высокой квалификации;

• необходимость устойчивости к изменениям в окружении (в самом широком смысле слова «окружение»);

• снижение лишних расходов, где только возможно.

Иными словами, при производственном подходе разработчик задается не только вопросом «как это запилить поизящнее?», а еще и «насколько дешево, просто и удобно возможно будет это сопровождать, расширять и развивать?».

Фабричный гудок, разумеется, звучит не так ярко и бодро, как «We are the champions»9 (и автор позволит себе мелкую пакость, указав, что эту песню по канону поют до выхода на бой и уж никак не после победы). Но дела на фабрике идут, контора пишет, касса выдает деньги — день за днем, месяц за месяцем. Олимпийское же золото абсолютному большинству чемпионов доведется увидеть либо в сладком сне, либо на груди более успешного противника.

«Вы из тех героев, что из последних сил рвут противника, завоевывая олимпийское золото? Спасибо, мы вам обязательно позвоним».

Техническое задание или технический проект?

У этого вопроса даже не двойное, а тройное дно. Первый смысловой слой: а в чем, собственно, разница, если она вообще имеется? Для граждан, исповедующих религию «просто пиши код», разницы, разумеется, никакой нет (будь автор сородичем ехидны, то непременно заметил бы, что в руках «просто пишущего код» любой язык программирования со временем неизбежно превращается не только в Brainfuck, но и в Oook! Но автор — человек вежливый и ехидных замечаний, конечно же, себе не позволяет).

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

Второй смысловой слой ставит перед соискателем ловушку выбора: «Вот вы, юноша, как предпочитаете — по техническому заданию или с техническим проектом? А учитывая, что задание четкое, а проект размытый? И как, по-вашему, можно ли это совместить?» Маленькие радости для любителей простыми вопросами создать для незнакомых людей неуютное положение.

Как перевести на русский «предпочитаю работать по четкому ТЗ»? Очень просто. Кто-то должен взять бумагу и написать пошаговую инструкцию — какие объекты создать, как и что расположить на форме, какие действия должны выполняться системой в ответ на действия пользователя, ну и еще сотня разных подробностей. Возникает вполне логичный вопрос: если все уже продумано, расписано, «разжевано и в рот положено», зачем нам вообще разработчик? С выполнением пошаговой инструкции справится даже школьник выпускного класса, не говоря о студентах первого-второго курсов: «Какие у вас там заявлены ожидания по зарплате? Спасибо, мы вам обязательно позвоним».

Эффективная разработка не допускает существования «технических заданий» и четко разграничивает компетенции:

• сбора требований;

• системного анализа;

• технического проектирования.

Действуе