Преамбула
В последнее время встречаю много руководителей в IT, которые проповедуют, что ТЗ, таск-трекеры, аналитики, архитекторы и документация в разработке никчемные "вещи" и не стоит на них тратить время и средства. И ладно если бы люди делали внешние проекты, там это как-то я еще могу обосновать, но когда дело касается внутренней автоматизации бизнеса, тут я не могу с ними никак согласиться и говорю, что Вы просто не умеете их "готовить".
Очень распространенная схема работы по автоматизации заключаются в том, чтобы свести вместе бизнес-пользователя и разработчика и они вдвоем решают любые задачи и это очень хорошо работает. Только как правило в таких компаниях конечный финансовый результат формируется руками и в лучшем случае в Excel-е, плюс сам результат показывает как компания отработала за прошлый период, а не как компания работает сейчас. Как говорит один уважаемый мной человек и владелец компании: — IT предоставляет мне результат работы, но этот результат посмертен. Может возникнуть вопрос, а зачем держат такой IT? И здесь я могу предположить два варианта, это регламентированный учет, от оплаты налогов никто не освобожден и второе это "какой-то" управленческий учет из которого "как-то" можно получить "какие-то" цифры на основании которых можно получить результат и на основании этого результата сделать вывод, что компании еще можно дальше работать и не расходиться некоторое время. При этом руководство компании из-за страха потерять, то что имеет, говорит у меня хороший IT — департамент. Ну и результат всему этому отсутствие доверия между бизнесом и IT.
Как говорят ученые, у любой компании всего одна проблема, остальное все задачи и это проблема называется — ПЕРСОНАЛ. Уменьшить влияние этой проблемы на бизнес может задача сформулированная примерно так: "Уменьшить человеческий фактор". Итак поехали....
Зачем нужен таск-трекер?
Если все общение свести в одно место и в этом месте фиксировать все, то снимается очень много вопросов связанных с коммуникацией. Есть вопрос — есть задача, нет задачи — нет вопроса. Плюс практически полная прозрачность для руководства, что происходит. Как результат уменьшение человеческого фактора и времени на выяснения отношений, про нервы сейчас промолчу, хотя они тоже очень важны. На мой взгляд даже коммерческие продукты полностью оправдывают свои затраты и по времени и по деньгам. Здесь главное препятствие, это руководители среднего звена, которым прозрачность часто бывает совершенно не нужна, так как в "мутной" воде им проще существовать.
Зачем нужен аналитик?
Вернемся к схеме бизнес-пользователь — разработчик. Что один, что другой, каждый варится в своем "киселе" и обычно плохо понимает, что творится в соседней "кастрюле". Плюс очень расхожее мнение, что бизнес-процесс и алгоритм программы это одно и тоже и это мнение присуще как руководителям компаний, так и горе-руководителям IT подразделений. Плюс бизнес требует, чтобы бизнес-пользователь занимался непосредственно своей работой — выполнял бизнес-функцию, а от разработчика, чтобы тот больше времени писал код, а не болтал с коллегами, часто не забывают "мотивировать" тем, что содержание разработчика обходится компании в копеечку. Так вот аналитик это как-раз тот самый человек, который профессионально делает следующие вещи: формализация требований, согласовывание требований с руководством и разработчиком, написание ТЗ, тестирование, написание инструкций и документации. И самое главное он может объединять в себе несколько бизнес-функций, а то часто бывает так, что что-то автоматизируют, а оно раз и вошло в конфликт с какой-то другой бизнес-функцией и все приходиться переделывать сначала, а иногда и несколько раз. Когда в компании всего 1-2 разработчика, конечно можно обойтись и без аналитика, но когда разработчиков больше, то по мне аналитик просто необходим и он оправдает себя сэкономленным временем и повышением вероятности получения результата, плюс освобождает бизнес-пользователей и дорогих разработчиков от не присущих их деятельности функций.
Зачем нужно ТЗ?
Холиварная конечно тема и много народу в ней "погибло", поэтому скажу лишь одно, я рассматриваю ТЗ как формализованное соглашение трех сторон о содержании и реализации задачи. Три стороны, это бизнес-пользователь, разработчик и тот кто за все это платит. Почему так часто негативное отношение к ТЗ? Думаю, что просто не видели хороших ТЗ и сами написать не могут. Ведь как часто бывает, разработчик говорит, что надо ТЗ, бизнес-пользователь в течении продолжительного времени его пытается написать, в результате чего появляется многостраничный труд, который просто прочитать требует невероятных усилий. В результате разработчик — недоволен, бизнес-пользователь — недоволен, руководство недовольно результатом, вывод для всех — ТЗ нам не нужно.
Зачем нужен архитектор?
Как аналитик обобщает бизнес функции, так и архитектор обобщает техническую реализацию. И когда IT отдел вырос за 5 человек, архитектор просто необходим как воздух. Что бывает при росте компании, когда нет архитектора. Первое это разделение IT по кастовой принадлежности (1С, Web, Системные администраторы, BI, C# и др.), причем каждая каста пытается тянуть "одеяло" на себя в ущерб общей задаче, часто это происходит просто на подсознательном уровне, когда человек хочет как лучше, но в силу своей ограниченности получается как всегда. Здесь основная сложность это взаимодействие между кастами, которое всегда зеркально отражается сложностью взаимодействия между модулями конечного продукта автоматизации.
Второй вид разделения это разделение по бизнес-функциям, это когда один разработчик отвечает за реализацию ограниченного набора функций и кроме него никто не знает как это работает и здесь все держится на всемогущем "АВОСЬ". Когда отдел IT вырастает, бывают еще более "смешные" случаи, например создается отдельный отдел архитектуры, который просто живет своей жизнью отдельно от всех других подразделений IT. Или в каждом подразделении IT выделяется отдельный архитектор, при отсутствии главного архитектора. Этим всем я хочу сказать, что основная роль архитектора это объединение реализации технической части, что в свою очередь ведет к производству единого целостного продукта.
Подсознательно многие руководители IT понимают необходимость архитектора, но когда начинаешь их спрашивать чем должен заниматься архитектор, то практически всегда получаешь один и тот-же ответ примерно такого содержания: процентов 20-30 своего времени архитектор должен заниматься разработкой архитектуры, а остальное время быть обычным разработчиком и писать код. Это как примерно в строительстве архитектор зданий 80 процентов своего времени, будет класть кирпичную кладку. Мои слова подтверждаются и рынком труда, где практически все вакансии на позицию архитектора требуют 5-7 летнего опыта работы "каменщиком", "крановщиком", "штукатуром" или еще какой строительной специальностью. Такие вакансии мне говорят лишь о том, что человек будет писать код или что архитектор ищется в кастовую группу и там он тоже большую часть своего времени будет просто писать код.
Так чем же занять архитектора? На мой взгляд одна из задач архитектора это автоматизация работы разработчиков, т.е. разработка шаблонов проектирования и разработки и внедрение этих шаблонов в команду. Ведь как часто получается, в разработке достаточно много нудной дешевой работы, которую каждый разработчик выполняет и когда нет шаблонов, то обычно каждый раз разработчик пишет свой "велосипед" и как может решает (обычно очень неохотно) задачу самостоятельно не используя опыт "соседа". Т.е. задача повторного использования кода на мой взгляд это именно задача архитектора.
Еще одна задача, которую можно дать архитектору, это решение вопросов производительности, только не по факту, когда десяток пользователей запустили одновременно десять тяжелых отчетов и вся система легла, а когда разрабатывается архитектура и формируются бизнес-процессы. Вот здесь подавляющее большинство компаний с производительностью героически сражается именно постфактум и им даже в голову не приходит, что может быть как-то иначе и вовсе необязательно сражаться с ветряными мельницами. Очень забавно слышать, когда разработчик говорит что смог оптимизировать отчет и он теперь выполняется не 3 часа, а всего 30 минут или какой-то документ проводится теперь не 10 минут, а всего 2 и бизнес ему говорит, о как круто. Из этой забавности вытекает еще одна важная задача архитектора, а именно экономия времени пользователей и разработчиков. По мне бизнес пользователь, а тем более разработчик не должен ждать "систему", когда она там что-то сохранит, посчитает и выведет ему на экран или просто переключит окна, ведь время пользователей это один из самых дорогих ресурсов, за который компания платит реальные деньги и кому как не архитектору решать эту задачу. Ожидание пользователей является второй причиной недоверия бизнеса к IT, ведь во многих компаниях нормой является долгое ожидание отклика или зависание системы, а если бизнес начинает требовать что-то с пользователей, то часто слышит в ответ, так система висела/медленно работала.
Ну и из важных задач архитектора хочется отметить еще работу над инцидентами и представление архитектурных решений, так чтобы вопрос, который вдруг появился мог быть закрыт раз и навсегда с помощью изменения архитектуры продукта, это не панацея, но часто решает задачу с минимальными затратами.
Зачем нужна документация?
В этом вопросе ситуация похожа с ТЗ, многие начинали-пробовали и мало у кого получалось. По своему опыту скажу, что есть два момента. Первый, документировать надо все, от настройки хостов и коммутаторов, до внештатных регламентов и всех принятых решений. Последнее невероятно важно, поскольку очень часто, что-то сделали и не зафиксировали нигде, почему было принято такое решение, а потом когда вопрос повторяется все мучительно пытаются вспомнить почему так сделали и тратят на это уйму времени. Вторым моментом является разработка архитектуры хранения документации и разработка регламента работы с ней, это наиболее сложный момент, но хочу сказать — осилит дорогу идущий. Основным препятствием к этому является опять пресловутый человеческий фактор, когда монополист владеющий информацией, не хочет расставаться со своей монополией.
Тот кто осилит этот путь, получает в замен просто невероятный мощи инструмент в виде базы знаний в которой можно всегда найти ответ за того парня, которого сегодня не оказалось на месте и не лезть лишний раз в goolge. Многие говорят, что на ведение документации необходимы колосальные ресурсы, но так говорят те, кто не смог пройти этот путь и просто ищет себе оправдание.
Заключение
В начале статьи я слукавил, сказав, что я не согласен с отсутствием чего-либо при внутренней автоматизации. Без всего этого можно обойтись и в подавляющем большинстве все без этого прекрасно живут, обуславливается это двумя факторами. Первый это когда генеральный директор не является собственником и тут он сам является человеческим фактором, так как прозрачность ему как правило ни к чему. Второй случай, это когда норма прибыли сейчас в компании позволяет не думать об автоматизации и все воспринимается как данность и одна надежда на "АВОСЬ". К чему я это тогда все написал? Да просто хотел показать, что жизнь по другую сторону тоже существует, в очень небольшом количестве, но она есть.
Все выше основано лишь на моем опыте и не претендует на какую-либо исключительность. В своей статье я затронул лишь верхушку айсберга, в жизни все намного интереснее и многограннее.
Всем доброго дня и спасибо за внимание.
Автор: Пупсень и Вупсень
