Пионер автоматизации предприятий в СССР минчанин Геннадий Овсищер ​оказался в ИТ в 1972 году​, проработав в индустрии следующие почти 45 лет. dev.by публикует 37 принципов 68-летнего постановщика задач, сформулированных на протяжении долгой карьеры. 

Читать далее...

1. Утвердись во мнении: «Постановщик — это особый образ жизни»

Это значит, что ради дела (хорошей задачи) ты готов:

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

2. Постановщиком нельзя быть только на службе

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

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

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

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

4. Советы как ставить задачу могут давать все — от уборщицы до программиста

При этом советы уборщицы иногда более полезны, чем программиста.

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

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

5. Главный вопрос: «ЗАЧЕМ?»

Главный вопрос, который должен задавать себе и другим постановщик в процессе обследования и написания постановки, звучит так: «ЗАЧЕМ?». В расширенном варианте: «Зачем это так делается?» или «Зачем ты так делаешь?». Умные и убедительные ответы на такие вопросы требуют обязательной реализации в будущей постановке. Кроме того, эти ответы позволяют тебе отстаивать проектные решения на стадии дальнейшего согласования.

Ответы типа «для контроля», «для формирования других отчётов» или другие односложные ответы — это не ответы.

6. Бойся ошибиться при проектировании

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

И здесь важно признавать во всём свои ошибки. Не ссылаться на:

• так согласовал
• так понял
• не это имел в виду и т.д. 

7. Всегда во всём сомневайся.

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

8. Коллекционируй ошибки

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

9. Перед началом работы на объекте определись с мотивами заказчика 

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

В конечном счёте, мотивами, которыми руководствуется заказчик, принимая решение об автоматизации, могут быть следующие:

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

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

10. Не жалей времени на обследование

Разумеется, играет роль:

• для кого эта «задача»? Одно дело, разработка конкретной функции для одного рабочего места, и другое —разработка интегрированной системы с распределённой базой данных в многопользовательском режиме;
• ты один как разработчик или это коллектив, желательно «единомышленников»;
• это первая задача в данной сфере деятельности? Или на другом объекте ты занимался подобной задачей и тебе известен круг вопросов, которым занимается данный объект автоматизации, а главное, как он решает эти вопросы;  
• каким временем ты располагаешь для разработки и внедрения;
• ты будешь заниматься задачами на объекте, на котором всё делается «без компьютеров» или кое-что всё-таки делается с использованием программ
• на объекте имеется структура (отдел, бюро, группа, специалист), которая ведёт или собирается вести работы по автоматизации процессов управления.

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

Целеустремленное, квалифицированное обследование и анализ позволяет обоснованно определить объекты и функции управления, подлежащие автоматизации, установить очерёдность разработки и внедрения задачи, то есть сконцентрировать усилия и средства там, где они дадут наибольший эффект.

Обследование и анализ объекта производится на предпроектной стадии, на базе которой разрабатывается техническое задание (TЗ) или концепция и стадии проектирования (дообследование) — в начале этапа непосредственной разработки задачи (технического проекта, ТП).

11. Внимательно читай и изучай нормативные материалы

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

12. Не стесняйся спросить и переспросить.

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

13. В процессе обследования старайся, по возможности, продумывать и способы решения

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

14. Говори с заказчиком на одном языке

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

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

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

15. Последней фразой

в беседах при обследовании должна быть: «Что я у вас ещё не спросил по этому объекту обследования? И что бы вы хотели рассказать, о чем я не спросил?». Как правило, после этих слов, можно получить нужную нам информацию.

16. В процессе обследования по одному вопросу «пройдись» дважды

При этом хорошо бы с разными специалистами.

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

И через него по возможности проверяй свои проектные варианты решения.

18. Все решения с заказчиком оформляй протоколом

Используй принцип «разумного формализма». Даже результаты совещания оформляй протоколом. Вот вопросы (неполный перечень), которые должны быть в том или ином виде отражены в протоколе:

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

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

19. В каждой задаче должна быть «изюминка»

Если она есть, то считай, что постановка удалась. Такими изюминками могут быть:

• упрощение процесса формирования исходных данных;
• формирование выходных данных для пользователя, на основании которых принимаются оперативные решения;
• реорганизация структуры объекта (вплоть до сокращения численности работников);
• резкое сокращение трудоёмкости и времени получения нужных результатов.

20. Мы должны понимать, что от внедрённых задач существует, как правило, эффект в неявном виде

И его трудно оценить в стоимостном (количественном) выражении. Можно говорить о качественных показателях – ускорит, повысит, улучшит, предоставит возможность, создаст условия и т.д.

21. Держи под контролем все последующие процессы, которые происходят с твоим детищем.

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

И если в этом процессе ты обнаруживаешь недочёты или ошибки (в том числе и свои) — вмешивайся в процесс. Необходимо реагировать оперативно.

22. Автоматизация процесса на объекте — это совокупность следующих факторов:

• организационных
• алгоритмических (постановочных)
• технических 
• ПО

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

23. Старайся вначале задачу писать не на бумаге, а в уме (обдумывая решение)

Из моего опыта: если задача не пишется (не ложится на бумагу), значит, где-то в твоём воображаемом представлении о задаче есть ошибка. Даже бумага не принимает твоё решение. Обязательно пересмотри эти решения.

24. Всегда полезно «побиться о дурака»

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

И тут возможны два эффекта:

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

25. При сопровождении старайся не заглядывать в постановку

Она должна быть всегда «в голове». Это тренирует твою память и это ещё раз даёт возможность продумать решения задачи.

26. Смотри и читай чужие задачи — даже если они не твоей тематики

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

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

Вообще постановка является конструкторской частью создаваемого продукта. Из-за сложности программных продуктов здесь пока ещё не изобретён «метод Монжа».

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

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

Кроме того, согласованная с заказчиком постановка является заданием на программирование. И это тоже специфичный потребитель вашей постановки. Его мало интересует экономическая суть проблемы. Ему скажи, что на что умножить и разделить, ответь на вопрос: «Что будет, если…?».

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

Для справки. Метод Монжа — это правило проектирования точки в трёх проекциях с возможными дополнительными детализациями.

28. В процессе сопровождения программирования хвали программиста

В конечном счёте, он «раб» твоей идеи, варианта решения. А раба надо ценить и благодарить. Часто говори ему: «Это лучше, чем я предполагал и написал».

29. Позволяй программисту изменять процесс решения задачи, предварительно согласовав изменения

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

30. Думай о временных параметрах решаемой задачи

Бойся ситуации, когда из-за твоей задачи придётся увеличить размер суток.

31. Старайся тестировать сам.

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

32. Продумай и найди способ первичной загрузки данных в твою задачу

И здесь возможные решения:

• произведи загрузку данных из действующих систем;
• прими решения, что данные по задаче вводятся по новым объектам (начинаются с нуля). Итак, данные по новым объектам в новой задаче, а данные по старым объектам или вообще не вводятся, или вводятся в старой системе;
• создать механизм ввода по старым объектам учёта;
• обеспечить динамический довод данных в процессе эксплуатации задачи. 

33. По возможности, не занимайся одновременно несколькими задачами (особенно на разных объектах)

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

34. И уж совсем недопустимо сидеть на двух стульях — быть и разработчиком (конструктором) и программистом (технологом)

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

Со слов опытного программиста: «Когда «халтурил» один, задача долго не существовала. А вот когда в паре с постановщиком — до сих пор работает».

35. Если в процессе проектирования тебе удалось изменить структуру объекта или схему (порядок) документооборота, это отличный результат

Считайте, что ваша задача достигла результата, если пользователь сказал: «Благодаря вашей задаче мы в отпуск все сходили летом. И каждый день, как правило, уходим домой в 18-00 а не 21-00».

36. Заказчик, настаивающий на каких-то проектных решениях, всегда прав, если ты с ним согласен

37. Успех внедрения зависит от первого лица на объекте («принцип первого руководителя»)

Если он будет использовать данные из задачи, а не справки, которые ему делают клерки, то будут созданы условия, при которых информация на объекте первична, а сколько продано, сделано, испорчено, уворовано — вторично.  

Поэтому в разрабатываемой системе одна из важнейших целей разработки — создание сводных агрегированных отчётов для руководства объектами. 

45 лет в ИТ: «В 90-х в мои алгоритмы перестали заворачивать селёдку»

16 лет dev.by — «дефолтный» источник информации о беларусском ИТ

Вы можете...