Архив за Март, 2016

Тенденции в IT индустрии

Вторник, Март 22nd, 2016

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

Дисклеймер. Все нижеописанное  - гипотезы.

Первая тенденция. «Автоматизация ради автоматизации». Автоматизация умственного труда не дает того же эффекта, что и автоматизация ручного труда. Внезапно.

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

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

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

Вторая тенденция: «Прощайте мигающие огоньки».

В 90-х годах даже люди, платившие деньги из своего кармана, покупали «автоматизацию» для «престижу». Но когда деньги перестали плыть бурным потоком, калькулятор все-таки понадобился, и в 2000-х бизнесмены уже начали считать деньги на автоматизацию. А а 2010-х уже и Государственному сектору понадобилось, чтобы ПО было рабочим. Появился спрос на функциональное ПО, способное поддерживать интеграцию с другими системами и при этом соответствующее минимальным требованиям безопасности. Электронный документооборот постепенно перестает быть разговорами об «инновационном завтра». Были поставлены сроки, в которые электронный документооборот должен стать обязательным. С наступлением этих сроков государственный заказчик понял, что старая модель общения с подрядчиками должна быть пересмотрена. То же самое с немалым удивлением обнаружили и подрядчики. «Вы представляете, какие сволочи эти заказчики? Они не только не купили новые сервера за 100500 денег, так еще и хотят, чтобы программа работала!?!?»

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

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

Четвертая тенденция: «Моя хата с краю». Резкое возрастание организационной сложности проекта.

Сложность управления процессом разработки значительно увеличилась. Возросла сложность структуры предприятий, возникло множество аутсорсинговых вариантов. Зачастую разные части продукта производятся в разных, закрытых друг от друга политикой конфиденциальности компаниях. Это же касается и интеграции систем, разрабатываемых параллельно разными производителями. Чем выше отчужденность участвующих в разработке команд, тем дольше и дороже на выходе оказывается проект, и тем меньше вероятность, что он будет завершен успешно. И в этой «мутной водичке» появляется соблазн вместо выполнения своих непосредственных обязанностей заняться «грязными играми». Смотри «команду физиков» в книге «Жизнь в пузыре» Ашманова.

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

Разработчики стремительно утрачивают способности к анализу. Многие уже просто шарахаются от схемы БД в 200+ объектов, 500+ связей. Хм… дюжину лет назад с такой схемой легко работали тестировщики. Инженерам все сложнее становится читать длинные документы и статьи. Статьи в 3000+ знаков - это «ниасилил, многабукф». В качестве вишенки на торт абсурдная недавняя история. Разработчик не смог прочитать тикет с подробным описанием. В ходе ответов на вопросы разработчика, автор тикета просто ссылался на куски начального описания тикета. Т.е. разработчик не смог прочитать тикет ни с первого, ни со второго, ни с третьего раза.

PS. Напоминаем. Это лишь гипотезы. Вполне возможно, что сейчас трава по-прежнему зеленая.

be happy don’t worry

Защита от впихивыния невпихуемого

Понедельник, Март 21st, 2016

Попытка решить слишком много задач приводит к снижению производительности, нервотрепке и отрицательному естественному отбору. Снижение производительности на 15-20% это совершенно нормально. Вполне может быть и в два – три раза. Отрицательный естественный отбор – сотрудники, имитирующие бурную деятельность, получают плюшки в виде премий и повышения в должности. Сотрудники, которые работают, уходят работать в другой офис. Процесс этот может протекать достаточно бурно и через пару-тройку лет весь средний менеджмент организации может оказать укомплектован исключительно имитаторами.

Для предотвращения впихивания невпихуемого есть довольно простые правила.

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

Невыдуманная история. В одной из фирм маркетологам запретили чисто устную постановку задачи. Сначала трекер. Только потом можно рассказать устно. Поток гениальности снизился вдвое.

“Если ты не можешь записать идею на родном языке - возможно, тебе рано о ней рассказывать?”

2. Еще до фазы управления идея должна пройти минимальный анализ.

Иногда все очевидно и анализ не записывается. Пример: “Под нового заказчика ООО “Атлант” сделайте новый проект в Jira & пространство в Confluence”. Потому как в регламенте написано про НДА, которое реализуется через разграничение прав доступа к проектам Jira и пространствам Confluence. Но под “поток гениальности” анализ нужно зафиксировать.

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

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

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

1) Представитель заказчика утверждает порядок очереди работ. Т.е. основное управление осуществляется через “очередь” работ. Чем выше в списке (”ближе к кассе”), тем раньше задачу начнут делать. и вот этот самый порядок в очереди утверждается на встрече представителей заказчика и исполнителя. А если заказчик адекватный, то функции управления очередью можно отдать ему полностью и сэкономить на зарплате менеджера в группе разработки.

2) Задача прожившая в очереди работ более определенного времени (подбирается на основании экспериментальных данных) закрывается автоматически (скриптом). Другой вариант - должна быть не длиннее чем N задач. Например, если в неделю сыплется 10-20, а делается 5-10 задач. То у 50-й задачи нет шансов быть сделанной. За те 6-9 недель, которые нужны, чтобы до нее добраться прилетит еще 100-130 задач. И, если хотя бы половина из них будет поставлена перед 50-й, то…

3) Задачи управляемые по датам (изменение порядка исчисления НДС с 1.04.года) висят в очереди как можно дольше, пропуская вперед все задачи с немедленным экономическим эффектом. Смысл в том, что задачи, управляемые по датам приносят экономический эффект только после наступления этой даты. И для максимизации прибыли фирмы нужно откладывать их на последний момент. Но, естественно оставляя запас по времени под различные риски.

Тонкий момент. Для простоты, пусть у нас будет процесс, без проектов. В этом случае управление осуществляется регламентом. По пунктам:

* Менеджер не имеет права отдавать указания исполнителям. Исполнителями управляет регламент работ.

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

* Менеджер (не обязательно этот же) может поменять регламент.

——–

Приложение. Дополнения, разъяснения и предупреждения.

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

Для справки. Фирма Хитачи несколько раз пыталась у себя производственную систему Тойота. У них хватало и опытных наставников из Тойота и денег и упорства. Но их производственная среда отличалась от среды Тойота. Итого: потеряв кучу денег они не смогли внедрить производственную систему Тойота и были вынуждены разработать другое прикладное решение под свою среду.

Вот небольшой список вопросов для определения, какое прикладное решение вам подойдет:

* Заказчик. Внутренний / внешний?

* Процесс или проект?

* Какова цена бага пропущенного в продакшен?

* Где находится ограничение системы?

* Сколько рабочих центров задействовано в работе?

* Взаимозаменяемы ли разработчики?

Это не все вопросы, но пока этого достаточно.

Для случая рассмотренного выше, ответы на вопросы будут следующие:

1. Заказчик внутренний. Упрощается взаимодействие. Не нужно «Закрывать контракты».

2. Процесс. Это означает, что задачи слабосвязаны и могут решаться независимо.

3. Цена бага незначительна по сравнению с преимуществом быстрого выпуска.

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

5. Данный рабочий центр практически не взаимодействует с другими в потоке создания ценности. Т.е. когда заказчик размещает заказ, этот центр разработки все делает сам без привлечения программистов, тестировщиков, аналитиков из других отделов.

6. Разработчики взаимозаменяемы.