не так страшны первые 90 проекта как вторые 90 проекта
Не так страшны первые 90% проекта, как оставшиеся 90% проекта
Переделку легко начать но очень трудно завершить.
В итоге: ездить можно но до окончания еще далекоооо…
Осталось много мелочевки без которой салон ‘не торт’
Volkswagen Caravelle 2016, двигатель дизельный 2.0 л., 140 л. с., передний привод, роботизированная коробка передач — тюнинг
Машины в продаже
Комментарии 17
А почему не мультиван сиденья?
Не понравились. И если диван снимать то надо 2 человека минимум — очень тяжелый.
Нафига покупать Фольксваген и делать из него хундай? Сразу Старекс нельзя было купить?
«У каждого психа своя программа» 🙂
Саравелла всем устраивает кроме сложностей в трансформации салона. Может был смысл брать Транспортер и из него делать «Starex» ну как говорится что есть то есть.
Спальное место каким то образом создать можно?
2-ой и 3-й ряды складываются в одну горизонтальную 2-спальную кровать
Форум АСУТП
Клуб специалистов в области промышленной автоматизации
Вопрос по Profibus Slave на S1200 (CPU1214 + CM1242-5)
Вопрос по Profibus Slave на S1200 (CPU1214 + CM1242-5)
Сообщение dsai » 08 фев 2020, 10:22
Добрый день, уважаемые коллеги.
Предыстория.
Заранее прошу прощения за вопрос, возможно он многим покажется элементарным, но мне требуется помощь. С контроллерами Siemens, и в частности с сетями Profibus, столкнулся впервые. С программирование и реализацией практически всех поставленных задач удалось справиться быстро, кроме одной: предоставить доступ к данным контроллера в режим Slave с помощью коммуникационного модуля CM 1242-5. Осложнилась задача еще и тем, что на данном этапе запуска, проверить работу данного функционала не представляется возможным.
Вопрос.
В TIA Portal V15 добавил данный модуль, добавил подсеть и установил адрес в настройках модуля. (Фактически неизвестно, что будет читать данные, то ли SCADA, то ли другой контроллер).Также в разделе i-slave communication добавил диапазоны используемых адресов для вывода (%Q..) и привязал в программе переменные к этим адресам.
Но уже тут столкнулся со следующим нюансом. Указать получилось только Slave адрес, так как в конфигурации нет мастера. Дальше после заливки программы в контроллер обнаружил следующее. На контроллере есть ошибки (о чем сигнализирует светодиод) и на модуле тоже (и DIAG и ERROR).
Диагностика показала следующее:
На модуле:
Module Exists.
OK
Error in lower-level component
На ПЛК
1. CPU error: New I/O access error during process image update
output 44 (14 bytes) will temporarily not be updated as part of process image PIP 0
(есть еще несколько таких же ошибок. количество ошибок совпадает с количеством диапазонов, настроенных в i-slave communication, и отпуты соответственно разные)
Собственно вопросы, с чем связано? что я не сделал или сделал не так?
Напомню, кабель связи к СМ1242-5 физически не подключен на данный момент, и мастер неизвестен.
Во вложении скриншоты и снятый лог. Заранее спасибо за любую помощь.
О нелинейности времени
Aug 6, 2016 · 2 min read
Не так страшны первые 90% проекта, как страшны вторые 90% проекта
Народная мудрость
Я писал заметку с этими мыслями ещё в первой версии своего блога лет 10 назад, но площадку с тем блогом заботливые коллеги благополучно закрыли и блог пропал. Рукописи не горят, но сохранить копию того блога я не удосужился, поэтому пишу заново.
Ещё когда я руководил командой программистов, я часто задумывался, почему программисты так часто срывают сроки? Причём искренне, без желания сделать хуже, а наоборот, с желанием сделать лучше! Потом, когда я строил дом, я задумывался над тем, почему строители так часто срывают сроки? А ещё я постоянно задумываюсь, почему люди так часто опаздывают?
И родил а сь у меня тогда теория, что это не только от безответственности происходит. А из-за того, что ощущение человеком времени подчиняется тем же законам, что и ощущение человеком других величин, таких как, например, сила или высота звука, яркость звёзд или экспозиция в фотографии.
Как известно, восприятие человеком силы звука логарифмично. То есть, упрощённо, звук, который нам кажется вдвое сильнее другого, на самом деле сильнее в 10 раз.
Аналогично с высотой звука. Высота нот в одной октаве отличается от высоты нот в другой ровно вдвое. А нам кажется, что отличие идёт на одну и ту же величину, то есть линейно. Это не совсем такая же зависимость, как с силой звука, но не в этом суть. А в том, что есть величины, которые при кажущемся линейном изменении на самом деле изменяются нелинейно.
А что, если и восприятие времени человеком определяется таким-же феноменом? И что когда нам кажется, что какая-то задача займёт двое больше времени, она на самом деле потребует в 10 раз больше? Ну или не в десять, но точно не в два?
А, поскольку мы оцениваем сроки всегда сравнивая с прошлым опытом и решением похожих задач в прошлом, это и даёт ответ на вопрос, почему люди так часто срывают сроки. Просто они не понимают об этой особенности собственного восприятия.
Хотя даже сам язык нам даёт подсказку о том, что время нелинейно. Иначе не возникло бы таких устойчивых словосочетаний, как “время летит” и “время тянется”. Полезно помнить об этой особенности, оценивая сроки самому и глядя, как оценивают сроки другие.
Александр Хачиян, AWG: «Не так страшны первые 90% проекта, как вторые 90%»
Сегодня говорим о ключевой вещи в любом интернет-магазине.
Кто-то скажет, что это товар, кто-то назовет доставку, а другие будут настаивать, что это клиенты. Но без IT-решения никакого интернет-магазина не будет.
IT – это основа основ любого E-commerce. А еще IT – это специфическая область, где нужны особые специалисты с определенными требованиями, потому что там есть характерные проблемы, и все очень часто не работает или работает плохо, все нужно очень часто оптимизировать или менять. И тут всегда вопрос: эту историю нужно делать внутри компании, потому что это «основа основ»? Или должны прийти специалисты, которые могут помочь выявить, решить, разрулить все те проблемы, которые есть, и сделать так, чтобы все работало?
Александр, в каких случаях на самом деле нужно идти во внешнее IT?
Внешнее ИТ всегда призвано усилить внутренне ИТ. У нас страна инженеров, мы очень пытливые люди и стараемся все делать сами внутри. Но, тем не менее, в какой-то момент мы упираемся в ограничение собственных ИТ-ресурсов, и тогда мы приглашаем внешние команды на усиление, либо на делегирование каких-то задач, в которых у внутреннего ИТ нет компетенций. Это не значит, что они некомпетентны в целом, это значит, что область ИТ очень широка, и не всё ребята знают.
Давай на примере. Допустим, я хочу развивать какую-то новую область ИТ. Я просто возьму разработчика себе в штат, который мне эту область ИТ разовьет. Вот, например, я решила строить маркетплейс.
Чтобы делать маркетплейс, тебе нужна очень большая команда с большой экспертизой. Просто так быстро ее нарастить очень тяжело. Рынок только формируется, «маркетплейсные» эксперты на рынке штучные, мы их всех даже в лицо знаем. Пригласить к себе в компанию таких людей, которые еще сформируют команду – это промежуток от полугода и, соответственно, у тебя откладывается процесс запуска твоего маркетплейса, минимум, на полгода в лучшем случае.
Намного эффективнее, если ты сейчас начнешь формировать команду, и параллельно пригласишь внешнюю компанию, которая тебе поможет быстро запуститься, выйти на рынок, чтобы начать зарабатывать и его захватывать.
Но внешняя команда придёт и сначала скажет, что ей надо все оценить, потом покажет план на полгода, а то и на год, распишет задачи. Это все равно не будет быстро.
Твоя внутренняя команда должна будет сделать все то же самое. Правильная внешняя команда должна понять твои бизнес-цели и построить план достижения этих бизнес-целей при помощи IT. Когда команда строит процесс, то лучше два раза спросить, чем один раз пойти не туда. Она правильно спрашивает, правильно фиксирует все те функциональные требования, которым должна отвечать будущая платформа, и формирует тебе план-график, когда и что ты получишь. А ты, соответственно, в эти даты и под этот функционал уже планируешь свой бизнес.
Когда мы говорим про внешнюю команду, мы говорим про людей, которые очень глубоко занимаются аналитикой бизнеса и делают именно бизнес-процессы. Зачем мне это делать извне?
Если ты можешь это делать внутри, это отлично. Если внутри у тебя нет таких людей или такие люди есть, но им некогда, потому что у бизнеса много других задач, то эти люди крайне важны именно на новые процессы. Просто руки разработчиков это не равно реализация проекта. Очень важно, чтобы разработчик получил четкую правильную задачу не из уст бизнеса, а из уст человека, который говорит с ним на одном языке.
Я не видела еще ни одного айтишника, который пришел бы на чужой код и сказал: «О, крутой код!». Они все говорят, что тут все не то понаписали и надо переписывать. У меня будет та же самая история, когда придет моя внутренняя команда на результат внешней команды.
Когда мы проектируем систему, мы не рассчитываем, что будут только разработчики, мы рассчитываем, что будет полноценная команда со стороны заказчика. Мы заказчику формируем полный состав того, кто с его стороны должен быть, чтобы можно было отвечать за эту работу, и это должен быть не один программист, это должна быть команда.
У команды есть разные роли и там, в том числе, архитектор, аналитики и уже потом команда разработчиков. Таким образом, систему, которую мы проектируем и делаем, мы передаем в эту команду, и она, получая ее со всей документацией, может дальше развивать ее самостоятельно. Это, если в целом у компании есть политика формирования собственных компетенций на 100%.
В каких случаях и с какими проектами приходят к вам?
Когда мы говорим про изменение бизнес-процессов именно в covid, это нужно было делать очень быстро, в дни, в недели, в часы. И как с внешними ребятами это реализовать?
Мы формируем такую «зондеркоманду», которая очень быстро погружается в текущие процессы. Она как детский врач, который ребенку показывает фигурку человека и спрашивает, где болит. Мы также открываем нашу омни-архитектуру и начинаем с командой заказчика изучать, как построены процессы и, буквально, за несколько часов нам становится поверхностно понятно, и как все работает.
Дальше мы формируем «quick wins» каких-то решений, которые позволяют за неделю или за какой-то короткий срок уже дать 80% эффекта. Следующим шагом мы формируем план реализации остального. По нашим кейсам, мы решаем самые большие болячки компаний, буквально, от недели до трех недель.
Ты можешь мне назвать пример какой-то компании, в которой вы это сделали в covid?
Таких компаний несколько. Приведу один из примеров – сайт не выдерживал нагрузок. Нами проведена оптимизация запросов в базу данных, оптимизация работы с сервером, оптимизация работы с кодом, небольшие корректировки в коде. Это у команды разработчиков заняло около недели, и в целом, сайт готов был выдерживать уже пятикратную нагрузку.
Второй пример – проблемы с процессами на складе. Компания не была готова к таким возросшим нагрузкам, и существующие процессы не были оптимизированы под такое огромное количество заказов. Мы сделали небольшую оптимизацию так, чтобы человеку не надо было три раза ходить в одно и то же место для сбора одного заказа.
А при чем тут вы и оптимизация процессов на складе? Это делают другие люди, и айтишники здесь вообще не при чем.
Мы же не только с сайтами работаем, мы в целом занимаемся всем omni в компании. Наша компания имеет экспертизу во всех системах, которые так или иначе участвуют в omni-процессах ритейла.
Какие еще боли клиентов вы решаете?
У клиента есть задачи развития и масштабирования. Он понимает, что, если сейчас он не будет быстро развиваться, конкуренты его съедят.
Какие компании вы масштабировали? Сколько у вас таких проектов и почему вы в этом эксперты?
Я не смогу перечислить все наименования компаний, у нас жесткий NDA с рядом клиентов. Но скажу, что это все очень крупные федеральные сети от 300 до 1 000 магазинов. Запросы иногда очень масштабные, когда заказчик хочет сделать изменение в целом по всей сети, а иногда узкоспециализированные в рамках, например, только сайта. Порой заказчик не готов в офлайне расширять полку товаров, а на сайте вводит.
У нас появилось несколько интересных проектов, часть уже успели реализовать, – это проекты по цифровой трансформации.
Во-первых, когда все процессы компании прозрачно протекают внутри IT-служб. Во-вторых, должна быть жесткая связанность этих систем. И чтобы такая жесткая связанность была, вся компания, а это конкретные люди, должна понимать, как это строить и как это делать.
К вам приходит компания и так и говорит: «Мы хотим провести цифровую трансформацию»? И что вы при этом делаете?
Разговор начинается с собственником, а собственник слов «цифровая трансформация» не употребляет, потому что, как и многие, также не понимает всего значения, которое они в себя включают. Он говорит о болях. А боли такие: за последние три года мы провалили несколько крупных проектов, потому что IT не умеет это делать, потому что оно где-то в коридорах бумаг застряло и дальше не двигается. И вот сейчас текущих задач у нас набралось, по оценкам IT, на три года.
По моему опыту, это надо умножать на два, т.е. получаем в итоге шесть лет. Через шесть лет это мне уже не нужно.
Как мне это знакомо. И что вы с этим делаете?
Мы погружаемся в структуру компании, в процессы компании и будущие задачи, а дальше мы понимаем, какими силами, ресурсами и процессами это должно достигаться, и при помощи каких систем.
Сколько занимает один процесс цифровой трансформации в компании?
В первую очередь, это месяц на изучение всего, формирование и согласование, что мы правильно поняли, как все работает. Второе – перед тем, как что-то делать, мы начинаем обучение. Это очень важно, потому что, если не провести обучение топ-менеджмента и среднего менеджмента тому, как строится процесс, они не будут понимать тех решений, которые мы предлагаем.
А дальше происходит реализация. К моменту реализации у нас, как правило, согласован road map с своими timeline, когда и что будет сделано согласно приоритетам компании. Такой процесс занимает, в целом, около года.
Это бесконечный процесс, но результаты видны уже где-то на 4-6 месяц. Команда довольна, она видит, что все движется, видит, что бизнес доволен. И бизнес действительно доволен, ведь он получает то, что IT делает все в срок.
Хорошо, вы завершаете проект и дальше вы этот проект просто передаете текущей команде, которая с вами работает или вы навсегда остаетесь на поддержке?
Мы сокращаем свое участие в пределах, которые согласованы с этой компанией в соответствии с ее политикой. Как я говорил, есть очень пытливые ребята, которые хотят все себе забрать, а есть компании, в которых формирование блока аутсорса – это нормально. Они у себя оставляют core-компетенцию, а то что в целом не core, им не особо интересно, и они отдают это на аутсорс.
В чем ваше преимущество перед другими IT-компаниями сейчас на рынке, и почему на эти задачи надо звать вас?
Ключевая компетенция компании – это хорошее понимание omni-канальных процессов omni-канального ритейла. Также мы очень хорошо понимаем все те боли, которые присущи крупному «кровавому» enterprise. То есть, когда самый банальный клиент хочет на сайте кнопочку «самовывоз», мы понимаем, что кнопочка «самовывоз» рисуется быстро, а вот реализация этого процесса может занимать около полугода. Для компании формирование процессов самовывоза штука очень непростая.
Сколько omni-канальных проектов вы внедрили?
Omni-канальные проекты – история очень большая, поэтому нельзя сказать, что мы больше сотни omni-канальных проектов сделали. Есть компании, где мы с нуля делали omni – это средний бизнес, и таких кейсов 5-7. Есть компании, где мы усиливаем текущий IT и забираем на себя какой-то блок, таких компаний, где мы отвечаем за определенное направление или за несколько направлений, порядка 10. Для примера, в Leroy Merlin мы отвечаем за множество разных направлений, причем, мы там работаем совместно с командой самого Leroy Merlin.
В ряде компаний мы отвечаем за блок мобильных приложений, в каких-то компаниях за блок в crm-системах, где-то за логистику.
Зачем вы отдельно будете закрывать блок мобильных приложений, если есть компании, которые специализируются на мобильных приложениях?
Наша компания тоже делает мобильные приложения, но мобильное приложение само по себе, которое видит клиент – это только фронт история. Очень важно, как это приложение будет получать данные, как оно будет порождать эти данные. Это как отдельный новый сайт, который тоже должен иметь какие-то интеграции, взаимодействие и систему.
Плюс у мобильного приложения есть свои потрясающие особенности, которые позволяют бизнесу его очень грамотно использовать, и важно отдельно строить процессы, которых раньше не было. Мы смотрим на IT-ландшафт, на бизнес-структуру и на бизнес-процессы и, соответственно, у нас есть картина «as is», а потом мы рисуем картину «to be», и происходит такой road map из одного состояния в другое, где есть несколько линий: линия системы, линия команд, линия процессов. Это такой документ к действию, а не отчетный документ в бухгалтерию.
После этого вам часто заказывают разработку того, что вы рекомендуете на основании аудита?
Предлагаете ли вы услугу аудита бесплатно в этом случае?
Услуга аудита у нас неприбыльна. У нас аудит, действительно, очень недорогой, учитывая, что там используются очень серьезные и экспертные ресурсы.
Сколько стоит ваш аудит?
Смотря какой. Если это просто аудит UX-дизайна, то он может стоить порядка 100-150 тыс. руб., если это более глубокий аудита ИТ-систем/процессов, от 400 тыс. руб. и выше.
Он занимает где-то порядка месяца?
Кто ваши целевые клиенты, которые к вам приходят? Что это за компании?
У нас был кейс «Альфа-банка», где мы оптимизировали интерфейс для контакт-центра, в котором работает 500 сотрудников. Задача заключалась в том, чтобы сократить поиск информации на 20 секунд. Мы сократили, у нас получилась 21 или 22 секунды. Компания стала экономить несколько миллионов в день.
Все ваши ИТ-проекты длятся в среднем год или больше?
Крупные проекты, действительно, быстро не делаются, но тенденция рынка такая, что клиентам нужно сейчас быстро что-то запустить, а потом на базе этого что-то делать. Поэтому средний запуск какого-то процесса проекта занимает от 2-х до 4-х месяцев. Это первая итерация, тот самый MVP, и мы всеми силами стараемся сделать его таким, чтобы его потом не пришлось хоронить и строить что-то другое.
В вашем стандартном проекте сколько обычно участвует ваших сотрудников? Какая у вас команда?
На разных этапах проекта подключаются разные специалисты. Не всегда люди, которые были в самом начале нужны до конца проекта. Суммарно, если брать по количеству людей, то в самом крупном проекте принимали участие от 20 до 45 специалистов.
20 человек в течение года… Сколько стоят ваши проекты?
Во-первых, они точно окупаются. Во-вторых, мы исходим из стоимости владения команд, которая включает в себя оценку ресурсов и срок реализации проекта. Стоимость владения рассчитывается из стоимости часа, час у нас от 2,5 тыс. руб. до 4 тыс. руб. в зависимости от эксперта. Таким образом, получается, что внедрение какого-то крупного проекта может стоить от 5 млн руб. до 40 млн руб.
И за сколько обычно окупаются ваши проекты?
Чем крупнее компания, тем быстрее окупается. Бывает, что первая версия запуска окупается буквально за считанные недели.
Любимая история с IT-проектами, когда тебе на входе говорят, что проект стоит 5 млн руб., а когда первые 5 млн уже потрачены, говорят, что теперь еще столько же, потому что все поменялось, и надо все делать по-другому. У вас также?
Не так страшны первые 90% проекта, как вторые 90% проекта. Да, это, к сожалению, частая история в рынке.
Из-за чего такое происходит? Первое – не зафиксированные четкие задачи. Просто говорят: «капаем туда, а там уже как пойдет, будем выяснять по ходу». Процесс оценивается предварительно – «примерно три месяца это займет и, наверное, вот столько будет стоить». Но если в процессе реализации мы постоянно идем не туда, делаем что-то другое, то начинаются сложности, и здесь очень важно, чтобы человек, который отвечает за реализацию проекта вовремя заказчику подсвечивал все эти сложности, которые появляются.
Не для того, чтобы защитить себя, а для того, чтобы заказчик понимал, что у него есть какие-то риски в проекте по изменению сроков, по увлечению потенциальных costs. Это поможет ему принять свое бизнес-решение: будет ли он продолжать инвестировать в это, понимая, что теперь это будет стоить больше.
Или бросит на полпути?
А вдруг он не окупится? Вдруг это какая-то не коммерческая история, а больше хотелось для галочки сделать; или это какая-то внутрикорпоративная история из серии «автоматизация процесса заявок на отпуска».
Как часто такие вещи вы выясняете в середине пути?
Очень часто выясняем. Но надо понимать, что чем больше проект, тем больше шансов, что он будет модернизироваться, это всегда закладывается. Бизнес – он живой. Когда бизнес ставит задачу в феврале, в мае концепция будет меняться, особенно, если пришел Covid-19.
Получается, что практически в любом случае, то, что мы обсуждаем в начале, в конце будет не таким и на это потребуется вдвое больше времени, чем мы обсуждали на старте?
Так не всегда. Подобных случаев бывает 30-40%. Чем больше срок проекта, тем чаще это происходит, и не потому, что на долгий срок сложно все оценить, а просто потому, что происходит много нового. Мы, взаимодействуя с заказчиком по бюджетированию, заранее говорим, что мы оценили это во столько-то и заложили сюда риски. Но, по нашему опыту, заложи со своей стороны на риски в два раза больше, и если сэкономишь – будешь молодец, а если нет, то у тебя будет маневр для движения и принятия решения.
Когда к вам приходит заказчик и ставит задачу, как он может убедиться, что вы правда сделаете то, что говорите?
Во-первых, мы не просто говорим: «да, сделаем». Мы рассказываем, как именно мы это будем делать, открываем, чертим и рисуем этот процесс.
Во-вторых, мы начинаем задавать бизнес-вопросы, которые периодически его ставят в тупик. Мы неоднократно получали интересный feedback, что в отличие от многих других подрядчиков, IT-компаний, мы часто бываем единственным людьми, которые не задают лишних вопросов. Мы приходим и начинаем говорить про бизнес, про деньги, про развитие, процессы, про людей и, таким образом, у заказчика формируется понимание и доверие к тому, что эта компания понимает, что ей надо, и понимает, как это будет достигаться. Далее мы показываем примеры.
Бывает клиент говорит, что ему нужно спроектировать будущую архитектуру, сделать аудит, но он не понимает, как это будет выглядеть и просит показать, что он получит и в каком виде. У нас есть несколько хороших кейсов, которые согласованы с заказчиками, и мы можем их демонстрировать, если это не конкуренты. А также есть кейсы, которые полностью обезличены.
Мы клиенту показываем, как будет выглядеть результат исследования, процесс формирования road map, как будет выглядеть калькуляция стоимости этого внедрения – в этом наборе документов наберется порядка десятка. Затем мы показываем, что он получит и как это читать, как этим пользоваться и как это применимо.
Кто те компании, которые вам доверяют?
С Leroy Merlin мы работаем уже четыре года, там и сайт, и мобильное приложение, и практически большинство микро-сервисных систем. Проводим работы по аналитике, разработке, дизайну, и реализовываем даже контентные проекты.
Есть несколько клиентов из сегмента fashion, с которыми мы делаем трансформацию. Например, большая сеть мультибрендовых магазинов No One, которые как раз пришли к нам во время пандемии.
Сейчас, когда ты сказал, что потребностей много, какое количество новых проектов вы готовы взять?
Каждый проект индивидуален. Мы готовы взять 1-2 крупных проекта и сформировать под них как процессы, так и команду. Запросов, действительно, стало намного больше. Мы не SAAS-платформа, как, например, PimPay или Retail Rocket, которые могут подключать неограниченное количество компаний, просто наращивая технологические мощности довольно оперативно. Вещи, которые мы делаем, делаются людьми и людей, к сожалению, быстро не воспитаешь. Мы и воспитываем, и приглашаем новых.
Александр, я могу тебе пожелать только быстрее воспитать новых людей на рынке для того, чтобы те собственники бизнеса, которые к тебе приходили и говорили, что им нужна IT-трансформация, могли быстрее найти у вас ответ, взять ресурсы, и чтобы у них все было хорошо и с трансформацией, и с omni и с масштабированием, и чтобы у вас тоже все было хорошо.