Записки IT~BP

2022-12-08 09:00:05 ​Друзья, в жизни я обычно сталкиваюсь с двумя разновидностями рабочего процесса. Сейчас я их опишу и выражу своё субъективное, оценочное суждение.

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

В зависимости от людей, которые встанут за этот конвейер, возможно два варианта.

Люди решают, что для них главное. Принять материал получше или передать работу другому побыстрее? Зачастую выбирают 2-ой вариант со словами: «А теперь ты, Сифа!».

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

По такой логике, например, работал завод имени Лихачёва, который выпускал грузовики ЗИЛ во времена позднего СССР и становления РФ. В конце конвейера был цех доводки, где бампер автомобилю подвязывался проволокой, чтобы хоть как-то его сдать.
Либо, так всегда работал Кутаисский автомобильный завод, выпускавший автомобили под маркой «Колхида» в СССР. Там был отборный отстой, который даже не всегда мог выехать за ворота завода своим ходом. Жило это только благодаря госплану, который выкручивал руки потребителям, заставляя их использовать то, что дают.

В современном мире с таким подходом долго не протянут. Указанных выше заводов ныне нет.

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

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

Например, именно поэтому производительность труда в промышленности ФРГ куда выше, чем в РФ. Нет, наши тоже умеют и могут работать, просто не везде есть культура производства.

А теперь моё личное, субъективное, оценочное мнение.

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

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

Какие у вас мысли о производственной культуре? Делитесь в комментариях.

Ваш эксперт IT⁓BP — Сэм Якушев Открыть/Комментировать

2022-12-07 19:35:33 Обсуждали сегодня с партнёрами интеграцию IT~BP в «Лидеры производительности» — государственную программу подготовки управленческих кадров. Открыть/Комментировать

2022-12-06 09:00:08 ​Как бы ни было грустно, но мы разбираем последний шаг из цепочки повествования о срыве сроков. Главное, чтобы оказалось полезно и применимо на практике.

Управляем рисками и собираем статистику

Хорошей идеей будет заложить бюджет по деньгам, ресурсам и срокам больше, чем в смете. Это на случай если что-то пойдёт не так. Просто заложите между этапами буфер в сколько-то процентов от стоимости этапа. Но никому и никогда не сообщайте о размере этого буфера и его существовании вообще.

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

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

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

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

Подведение итогов

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

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

Помним, что бизнес-заказчик — это тоже участник проекта. Он тоже выполняет работу над проектом, причём важную. А не только приходит за готовым результатом.

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

Даже более того. На самом деле ровно такие же проблемы возникают при постройке частного дома либо при работе отделочной бригады. Часто возникают.

Ну а ещё, мы наконец-то узнали, что такое ТЗ на самом деле, и почему просить написать «нормальное ТЗ» бизнес-заказчика — плохая идея. Открыть/Комментировать

2022-12-05 09:00:07 ​После того, как мы передали образ системы разработчикам или IT-команде, нужно сделать следующие шаги. Продолжаем цепочку повествования: «Программисты срывают сроки. Что делать?»

Проработка требования и разбивка на этапы

Допустим, что вы работаете над проектом, разработка которого занимает несколько календарных месяцев. Значит, вам необходимо проработать требования. Если написать вижн (видение системы) занимает 1-2 часа, предварительная оценка — 0.5-1 часа (простая рыночная статистика), то проработка требований — очень длительный процесс. Точную оценку на проработку требований вы должны получить в момент формирования предварительной оценки системы в целом.

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

Вы же должны будете согласовать проработанную постановку задачи? Значит и вы, как нетехнический специалист, должны её понимать. Вряд ли вы до конца поймёте архитектурную схему, схему потоков данных, описание API и прочее. А пользовательские сценарии — поймёте.

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

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

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

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

При проектировании необходимо представить себе поэтапную разработку приложения. Каждый этап должен включать в себя реализацию каких-то пользовательских сценариев целиком. Это важно.

К каждому этапу необходимо прописать критерии сдачи и сценарии, проверяя которые вы, как заказчик, убедитесь, что работа выполнена в полном объёме.

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

Длительность этапа не должна превышать нескольких месяцев. Чем длительней срок разработки, тем выше риски, что что-то пойдёт не так. Риски растут не линейно, а по параболе (для простоты).

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

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

2022-12-02 15:44:05 ​Что отличает старшего программиста от обычного программиста? Далеко не уровень «хард-скилов», а уровень мышления человека. Совершенное знание языков программирования и инструментов разработки не сделает человека старшим программистом.

Почему так получается? Старший программист уже воспринимает систему целиком и может находить оптимальные пути реализации исходя из общего понимания. Ещё он обладает коммуникационными навыками для того, чтобы объяснить/договориться с бизнес-аналитиками, UI/UX, QA, руководителем проекта и другими участниками команды о новом для них способе реализации.

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

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

Ещё такие люди являются хорошими наставниками. Именно наставниками, а не руководителями. Они помогают вырасти коллегам. В том числе и до своего уровня. Конкуренция их не пугает, скорее порадуются новому соратнику.

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

Иногда говорят, что в IT основная рабочая сила — это middle developer. Возможно. Но основная движущая сила — это senior developer. Без их работы техническая часть сложного проекта может просто не сдвинуться с места, вне зависимости от количества middle developer. Открыть/Комментировать

2022-12-01 14:24:16 ​Разбираем следующее звено в цепочке повествования: «Программисты срывают сроки. Что делать?»

Передаём образ системы

Вам нужно как-то передать сформированный образ системы команде разработки. Процесс передачи очень важен, в нём есть свои риски. Часто первый говорит одно, а второй слышит (и даже читает) другое.

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

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

Конечно, можно переложить на программиста ответственность за решение бизнес-задач, в чём он не компетентен. В ответ он потом вас пошлёт писать правильное ТЗ, в чём будете некомпетентны уже вы. Так и будете ходить по кругу, пока кто-нибудь не сообразит, что дело не в вас двоих, а процесс разработки пора чинить на уровне отдела/департамента/дирекции, а не конкретного программиста.

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

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

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

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

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

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

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

У нас впереди ещё 2 важных звена в этой цепочке. О них мы расскажем на следующей неделе.

Поставьте в комментарии , если вам эта информация оказалась полезна. Открыть/Комментировать

2022-11-29 15:03:43 ​Сегодня продолжим цепочку повествования. Первая часть здесь.

Ставим бизнес-цель

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

Та бизнес-цель либо бизнес-задача, что вы себе представите, будет маяком, на который будет ориентироваться вся команда разработки, включая вас: «А вот то, что мы сейчас делаем, оно вообще нужно?»

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

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

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

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

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

Представляем себе систему

Как говорил Стивен Кови, мысленное творение предшествует физическому творению. Чтобы что-то создать в мире объективной реальности, вы должны это создать в своём воображении. Кроме шуток — нужно. А потом словами описать тот образ, который вы представили. Желательно письменно. На бумаге.

При постановке задачи для IT-специалистов всё работает ровно также. Если вы попробуете заказать произвести что-то, чего даже представить себе не можете, то результат вас поразит, но вряд ли это будет приятной неожиданностью.

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

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

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

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

А вы пренебрегаете такими действиями или активно используете в рабочем процессе? Открыть/Комментировать

2022-11-28 15:42:41 Техническое задание
Это документ или несколько документов, определяющих цель, структуру, свойства и методы какого-либо проекта. Иными словами, документ определяет не только то, что нужно получить, но и как это сделать.

Для интереса берём ГОСТ 19.201-78: «Техническое задание. Требование к содержанию и оформлению». Там написано, что техническое задание должно содержать разделы:

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

В целом, видим, что с 1980-го года ничего кардинально не поменялось. Для описания структуры и формы ТЗ хватает 4-х листов. Различные формы для написания спецификации на программное обеспечение на сегодня общедоступны. Ценность представляет не какая-то стандартная форма, а умение наполнять её содержанием.

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

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

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

Чем дольше что-то происходит, тем больше неустойчивости и неопределённости приобретает. Поэтому процесс реализации мы должны разбить на этапы, рассказать, что и на каком этапе мы ожидаем, а потом сказать, как мы это будем проверять. Чем короче интервалы разработки, тем меньше риск, что исполнители свернут куда-то не туда.

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

В своей практике мы в качестве технического задания и спецификации используем последовательность документов:

бизнес-требования. Изложение на бумаге от заказчика того, что он хочет получить от системы и особые требования к системе, которые у него есть.
вижн (видение, представление). Изложение на бумаге того, как мы услышали заказчика и как мы представили себе систему. Обычно это текст на 1-2 листа.
функциональные требования. Перечисление основных функций в системе на несколько листов. Обычно именно функциональные требования включаются в договор.
разбивка по этапам реализации. Тоже может включаться в договор.
макеты приложения и описание пользовательских сценариев.
если нужно, то архитектурная схема и схема потоков данных между интегрируемыми системами, иногда описание API (Application Programming Interface — формат общения с информационной системой для другой информационной системы).

Всё, кроме 6-го пункта, который обычно состоит из нескольких схем, может понять простой человек, не обладающий технической экспертизой. Примерно такой же логикой действий мы пользуемся, чтобы восстановить контроль над ситуацией. Завтра рассмотрим постановку бизнес-цели и представление системы. Открыть/Комментировать