Летают только красивые самолеты
Когда я узнал тему номера – «Ловушки для бизнеса», – внутри аж все заклокотало: ведь двадцать с лишним лет опыта и практики! О сколько нам ошибок чудных готовит просвещенья дух… Почти по Пушкину.
Но что русскому хорошо – немцу смерть. Если один проиграл, то чаще всего второй выиграл. Если кто-то попался в ловушку, значит, кто-то ее поставил. Получается, палка о двух концах. И повествование о тех самых ловушках начало превращаться в разговор глухого со слепым. Или как в известной картинке, когда с двух сторон освещают цилиндр и один наблюдающий видит его проекцию как прямоугольник, а другой – как круг, и оба правы. Поэтому, подумав, я просто решил написать историю трех скелетов в своем шкафу. Или историю трех уроков. Каждый в них увидит свое: кто-то улыбнется, кто-то посмеется, а кто-то намотает на ус.
Сразу оговорюсь: истории написаны, что называется, по мотивам. Поэтому все совпадения случайны.
История первая. «Б-софт» и Ко
Эту историю, я думаю, каждый так или иначе прошел в своей жизни. У меня она случилась практически в самом начале профессиональной карьеры. Я тогда работал в одной крупной ИТ-компании: внутри она была разделена на департаменты, каждый из которых вел свою группу проектов. Передо мной стояла задача создать прототип системы документооборота. И прежде всего – разработать ее информационную, а точнее, сущностную модель. Для этого меня определили в тот самый «Б-софт»-департамент, разрабатывающий платформу, на которой можно строить произвольные сущностные модели.
И вот я попадаю во вполне себе сформировавшуюся структуру, которой было уже больше года. Работало в ней тогда человек десять-двенадцать, может, чуть больше. Система была очень интересной, перспективной, и я просто горел проектом. Но…
В команде были традиции. Даже больше – это была почти семья: дни рождения коллег, дни рождения детей, посиделки, обедать все уходили и приходили всегда вместе. Сначала я восхищался этим. Однако была у команды еще одна традиция – по пятницам ходить на волейбол, а потом на совместное испитие пивка. А у меня тогда – совсем молодая семья, сыну года два. Да и спорт в этой жизни как-то прошел мимо меня. Короче, я эту традицию как-то не поддержал.
В итоге где-то через полгода (или чуть меньше) мы с руководителем «Б-софта» приняли решение, что хоть я мальчик и умный, но системы буду строить где-нибудь в другом месте. Расстались без обид, комфортно.
После этого я понял, что есть организации по типу «корпорация» и есть организации по типу «семья». В первом случае во главе угла стоят регламенты и KPI, во втором – отношения. Душевно работать во-вторых приятнее, но я хочу работать в первых. Может, я сухарь, а может, циник, но мне всегда интереснее именно задача. И если уж строишь структуру – подбирай тех, кто ей соответствует, кто именно ее и ждет. А то получится, что хочешь сторожевого пса, а заводишь пуделя, и оба недовольны.
История вторая. О прозрачности
Когда я занялся созданием учетно-логистической системы в одной из производственных компаний, я уже понимал и в экономике, и в аналитике. И даже немного разбирался в управленческом учете. И вот, оценив текущую ситуацию в компании, увидел, что она производит свою продукцию в разных концах нашей необъятной. И поставляет ее тоже во все концы нашей необъятной, причем железной дорогой. Стоимость доставки включена в стоимость товара. Иначе говоря, доставка «бесплатная». А расчет с РЖД производится котловым методом: то есть все затраты на доставку в течение месяца просто суммируются и оплачиваются одним счетом. При этом с РЖД-то расшифровку по объектам доставки мы, конечно, получали, но толком ее никто не смотрел. Просто раз в месяц или квартал делили на общий объем поставок, получали «отнесенную» стоимость доставки и добавляли к себестоимости товара. Всё пучком.
И вот я, умный весь такой, решил соотнести затраты на доставку к конкретным контрактам. Попыхтел, посопел, разноску счета РЖД настроил, контрактом всё насквозь прокодировал. Короче, как в сказке: по сусекам поскреб, по амбарам помел и получил-таки отчет волшебный, где в разрезе договоров доставка разнесена была. И явил на свет тот отчет: были контракты, по которым мы товар аж тысяч на пять километров возили и с учетом выставленных от РЖД счетов продавали его по этим контрактам в огро-о-о-о-мный себе убыток. По сути, доплачивали, чтобы его у нас забирали.
Испугался я ошибки злой в коде или сглаза вирусного какого. Ну не может же так быть! До утра над отчетом сидел, выверял. Ан нет – всё так и выходило: доплачивали. Отдал я тогда отчет руководителю ИТ-департамента, и понес он его в службу безопасности экономической. Те еще три раза перепроверить его заставили. Да что ты против цифр-то бессердечных сделаешь.
Пошли тогда безопасники к руководителям. И… уволили начальника безопасников. То ли за весть недобрую, то ли еще по какой причине. Но вынес я из той истории для себя два правила. Первое – что безопасники есть умные и честные. А второе – будь по жизни аккуратнее, когда цифры в системах информационных трогаешь.
А если серьезно: выбирай себе заказчика по душе. Если сам лукавый – то тебе и лукавый заказчик сойдет. А если правду-матку рубить любишь, то и заказчика выбирай, которому «ехать, а не шашечки»…
История третья. Про узелки
На дворе стоял 98-й год. Когда меня позвали в этот проект, я уже считал себя крутым программистом: знал семантику более двадцати языков, имел опыт разработки на Java (JDK 1.0), рисовал ER-модели, да и вообще имел стаж целых три (!) года. Ну почти три года…
Нужно было собрать приложение для проведения профессионального тестирования сотрудников крупной страховой компании. Модного сейчас слова «фрилансер» тогда еще не было, но суть та же: руководитель проекта собрал внешнюю команду программистов, распределил между нами задачи, а сам был и постановщиком, и методологом, и приемкой. Короче, всё, как теперь водится.
Мне досталась задача разработать структуру данных. Вообще, мне очень нравилось (да и сейчас получаю настоящее удовольствие) именно разрабатывать информационные модели, потоки данных и прочие архитектурные решения. За работу к тому же обещали вполне прилично заплатить, да и времени дали более чем достаточно – несколько недель!
С присущим мне рвением (то есть отложив всё на последний момент) я принялся за проектирование. Как настоящий конструктор, грыз карандаши (хотя проектировал, естественно, в ERWin), отправлял «полки? налево, полки? направо», нещадно двигая спроектированные таблицы на экране. В итоге, еще раз проверив, что разработанная структура данных позволит решить все поставленные в техническом задании задачи, пошел сдаваться.
Руководитель проекта, он же методолог, посмотрел на схему (а в ней было штук двадцать таблиц с кучей полей) буквально 10-15 секунд и спокойно произнес: «Тут есть ошибка». «Не может быть – я всё проверил!» – воскликнул я. «Ошибка есть. Ищи». «Ну так если вы знаете, где ошибка, то покажите!» Он вздохнул: «Я не знаю где, но она есть. Иди ищи».
Я провозился со схемой больше часа – всё работает! Иду опять к руководителю, начинаю объяснять. Он опять спокойно так говорит: «Это твоя работа. Если настаиваешь, чтобы я подключился, – 50% штрафа». В полной уверенности, что всё в схеме отлично, естественно, соглашаюсь. Где-то минут через двадцать мы действительно натыкаемся на запрос/отчет, который не получится выполнить на данной структуре…
Черт, ошибка-то смешная – за две минуты поправил. Работу сдал. Штраф схлопотал. Всё по-честному. Собираюсь уже уходить, и не выдерживаю: «А как вы поняли, что есть ошибка, взглянув на схему всего десять секунд?» Его ответ я запомнил на всю жизнь: «Понимаешь, есть правило – летают только красивые самолеты. А у тебя здесь узелок из связей образовался. Значит, не полетит».
Естественно, его слова я тогда не воспринял всерьез. Пришел домой и начал просто двигать таблички в старой схеме, чтобы распутать «узелок». Но так и не получилось…
Во всех следующих проектах я всегда придерживался этого правила. И практически все мои «самолеты» летали.
Опубликовано 06.02.2018
