Учить матерого начальника цеха оптимизировать доменную печь, когда ты 23-летний вчерашний студент? Стать топ-менеджером крупной компании до 30 лет, но перестать общаться с друзьями? Покупать излишне дорогой костюм, так как работаешь 100 часов в неделю и не успеваешь тратить зарплату? Разрушаем стереотипы про консалтинг. Ну, или подтверждаем.
В предыдущей статье про консалтингЧитать полностью »
Однажды мой хороший друг сказал мне: «вся индустрия аудита основана на том, что люди друг другу врут». Это как нельзя лучше отражало истинную причину почему банкам и другим финансовым институтам нужно получать заключение внешних аудиторов каждый год – для того, чтобы другие институты верили их финансовой отчетности.
Похожая ситуация в ИТ. Любая компания может сказать: «мы защищаем свои системы и следим за безопасностью передачи данных. Но так ли это? И насколько хорошо защищают? Cертификация ISO 27001 отвечает на эти вопросы за вас, и позволяет сэкономить время на доказательствах. Под катом пример подготовки к сертификации ISO 27001 одной маленькой, европейской ИТ компании.
Читать полностью »
Я работаю много лет в индустрии разработки программного обеспечения и последние несколько лет я активно вовлечен в консалтинг и pre-sales фазы. И я заметил, чтобы быть успешным лидером как для менеджера проектов, представляющего бизнес-сторону, так и для архитектора – технического представителя необходимо совмещать в себе технические и лидерские качества.
Для меня наиболее полезным и эффективным источником обучения являются книги. И я бы хотел поделиться с вами топ 10, по моему мнению, книг полезных для начинающих и не только лидеров в разработке программного обеспечения. Эти книги помогут развить и улучшить лидерские качества необходимые в данной индустрии. Я не буду перечислять знаменитые менеджерские бестселлеры такие как Laws of Leadership или Good to Great. Я порекомендую более целевые книги, которые будут, несомненно, полезны именно лидерам в индустрии разработки программного обеспечения.
Название всех книг будут указаны на языке оригинала, но вы без труда сможете найти многие из них и в переводе.
Читать полностью »
TL;DR. Многие стремятся к «тихому успеху» — делать работу, которая «говорит сама за себя». К сожалению, это неправильный ход в современном театре труда. Зачастую верно обратное — для офисного информационного сотрудника представление работы и есть работа. Да, внутренняя политика компании действительно несправедлива. Но посмотрим, как эффективнее сыграть свою роль в этом спектакле. Хотя статья содержит советы для консультантов, она даёт пищу для размышлений и работникам других профессий. По крайней мере, даёт возможность понять мотивы консультанта — прим. пер.
Недавно я прочитал книгу Кита Джонстона «Импровизация и театр». Восхитительная книга об импровизационном театре и, главное, как этому научить.
Книга вдохновила меня на несколько аналогий между импровизирующим актёром и консультантом, поэтому я написал серию из четырёх статей, вот первая из них:
Глава 1. Офис — это театр работы. В статье рассматривается центральная проблема — акт «представления» работы, перфоманса, и насколько он важен для современного интеллектуального труда, особенно для консультанта. Предлагается несколько идей о том, как думать на ходу, не скатившись в бред сивой кобылы (bullshit, BS).
Читать полностью »
Как превратить условно-работающую ERP в реальный инструмент управления производством и поставками.
Питеркин Сергей, Меркулов Михаил, «Райтстеп»
За последние годы, количество производственных предприятий, заявляющих о внедренных ERPсистемах, значительно возросло. И составляет уже не десятки, а сотни. Говорим мы прежде всего о дискретном производстве, а под «производственной ERP» подразумеваем любую систему, претендующую на это гордое название. По частоте наших «столкновений», наиболее распространенными «работающими в производстве» ERP являются — BaaN/InforLN, InforERPSyteLine, постоянно-растущая «армия» заводов с 1С, и в небольшом количестве SAPERP и прочая экзотика.
Данная статься будет интересна прежде всего «продвинутым» пользователям ERP, в большей степени с позаказным типом производства («вытягивание» под заказ или на склад, в т.ч. и «вытягивание» под прогноз спроса), тем, кто автоматизировал (возможно – «как есть») процессы учета хода производства, т.е. формирования производственных заданий (далее по тексту – ПЗ. В разных системах: SFC-заказы, Job-Orders, JOBs, Заказы на Производство, Производственные заказы и т.п.) и их отслеживания, но так и не смог уверенно производство (и поставки – МТО (Материально-Техническое Обеспечение)) планировать, как и не смог поставить мониторинг производства, в т.ч. и позаказный. С непрекращающимися попытками все-же запустить планирование, и/или с попытками обеспечить планирование с использованием волшебных алгоритмов и/или систем типа APS, MES.
Иногда бывает так:
— Приезжайте, у нас упало. Если сейчас не поднять — покажут по телевизору.
И мы едем. Ночью. На другой край страны.
Ситуация, когда не повезло: на графике показан резкий рост нагрузки на СУБД. Очень часто это первое, на что смотрят администраторы системы и это первый признак того, что наступила жопа
Но чаще речь идёт про какие-то типовые вещи. Например, заказчик столкнулся с низкой производительностью системы документооборота. По понедельникам и вторникам система падала, они перезагружали сервер, и потом всё поднималось. Захлёбывалась база данных. Хотели докупить оборудования (что долго и дорого), позвали нас просчитать смету. Мы им посчитали смету и заодно предложили разобраться, что же именно тормозит. За три-четыре часа локализовали источник проблемы. Выяснили, что это медленные запросы в базу данных и неоптимальные схемы индексирования. Создали недостающие индексы, поковырялись с оптимизатором запросов в Оракле, некоторые проблемы потребовали изменения кода — поменяли условия поиска (без изменения функциональности), заменили часть запросов на использование предрассчитанных представлений. Если бы у них был нормальный человек по БД — могли бы сделать то же и сами. Но вместо нормального человека был аудит базы данных раз в полгода крутыми ораклистами — они выдавали общие рекомендации по настройкам и железу.Читать полностью »
Разработчик-консультант — довольно большая редкость в странах СНГ. Компании не понимают зачем нанимать эксперта на какой-то срок и платить больше, чем рядовому сотруднику. Тем временем на высококонкурентном европейском рынке появились консалтинговые агентства, которые связывают высококвалифицированные таланты с требовательными заказчиками. И для больших компаний стало нормой подписывать 1-2 консультанта на команду.
У меня за плечами 15 лет работы по обычному договору найма на постоянной основе. Но в этом году я решил попробовать каково это быть консультантом, приходить каждый день к заказчику и не знать какой будет следующий. Вопросов было много и как экспату нужно было разобраться в рисках.
Читать полностью »
Россия иррациональна. Есть правильные практики, есть сто раз ощупанные грабли, но всё равно с завидным постоянством случается что-то эпическое. Иногда по причине: «Ну уж меня-то точно пронесёт», иногда: «Всегда так делали, и работало», иногда просто из-за ошибок. Возможно, в генах.
Первый яркий пример невероятной дичи (детали немного изменены по требованию безопасников). Заказчик занимается капитальным строительством. Заказал несколько лет назад у подрядчика систему, которая управляет всем этим (в частности, сметными работами). Система была установлена на десятке немаленьких объектов, внедрена. Внезапно заказчик решил потребовать выдать ему исходный код. Как оказалось, у их имеющегося подрядчика были планы на то, что они проведут разработку софта, а потом будут продавать результат как SaaS по рынку. В договоре про код ничего не сказано. Поругались.
Когда позвали нас разбираться, там было примерно 10 разных версий ПО (релизы от 0.9 до 2.4). Есть исходники 1.5, эта версия собиралась когда-то из них. Документации нет. А систему надо дорабатывать и развивать. Посчитали «переписать всё заново» и «доработать 1.5» и остановились на втором — TtM три-четыре месяца против года. Научили собирать спецов поддержки, поправили исходники, свели кодовые базы, сделали инфраструктуру, организовали одну «разливочную», куда принимается исходник, там собирается и дистрибутируется. Это стоило нам и заказчику большого количества геморроя.
Заходите, покажу ещё примерно то, как можно поошибаться с процессом разработки, и к каким интересным последствиям это приводит. Читать полностью »
Продолжаем рассказывать о том, как действовать на каждом этапе внедрения IdM, чтобы система управления правами доступа работала максимально эффективно именно в вашей компании. В предыдущих статьях больше внимания я уделяла тому, что нужно делать самим в своей компании (в дальнейшем также буду это делать). Но в какой-то момент пора «выйти в свет», и сегодня поговорим об этом.
На рынке могу выделить три типа компаний – консультанты, интеграторы и вендоры. У каждого своя зона ответственности и компетенции.
К кому из них идти именно вам?
Когда речь заходит о роли аналитика в IT, то всегда приходится добавлять кучу уточнений. Бизнес или системный аналитик? Анализ в продуктовой разработке или в проектной, как это, например, часто бывает в консалтинге? На внутренней разработке или на заказной?.. Заказчика государственного или негосударственного? И так далее.
До прихода в Туту.ру я работала в IT-консалтинге на ERP-проектах и в заказной продуктовой разработке, здесь же я занимаюсь системным анализом во внутреннем продукте «Авиа». Отдел системного анализа у нас состоит из 9 аналитиков и 1 технического писателя. Далее на своем опыте я расскажу, что меняется в голове специалиста и в рабочих процессах при смене формата деятельности на внутреннюю продуктовую разработку с точки зрения анализа, а заодно поделюсь, как устроен процесс в целом у нас в Туту.ру.
