Записки IT~BP

Всем привет! Сэм на связи! Сегодян впервые провели закрытый вебинар про проверку работы ИТ-команды! Считаю что контент получился отличным, ещё шлифанем активности в течение вебинара и будем готовы на него приглашать широкую аудиторию) О чем говорим: - Что поможет определить уровень "нормальности" работы вашей ИТ-команды или аутсорсеров - Как нетехническим специалистам понять качество кода (!!!) - Определить проблемы с качеством продукта и их первоисточники - Свободно принимать решения о стоимости и сроках разработки не теряясь в дебрях технических сложностей - Заранее распознавать и недопускать развития проблемыв ИТ-команде и взаимодействии с подрядчиками В этом нет ничего катастрофически сложного, всё вам точно под силу. IT~BP для этого и было придумано! И делюсь первым тезисом - "Не пытайтесь использовать технические показатели, чтобы определить влияние на бизнес. К этому можно будет перейти после измерения бизнесовых показателей." Поймите как отражается работа ИТ-продукта на операциях бизнеса - это станет отправной точкой и для вашего понимания ситуации и для взаимодействия с разработчиками. Кстати, напишите Кате Полянской, если хотите попасть на один из следующих вебинаров @Kate_BDD

Надо ли держаться за старое?! Всем, привет от Ильдара! Нашел в офисе случайно свою машину начала 10ых годов 😍❤️‍🔥🔥 А вообще свой первый ноут IBM купил в 2005 и с тех пор только они, потом Леново 💻 Минутка философии - часто так бывает что мы привыкаем к чему-то, конкретному бренду, определенным практикам и фреймворкам, потом транслируем это командам, а через какое-то время спросив условного Васю - "а почему ты так делаешь?" можно услышать "ну тут всегда так делали!" И хорошо если вы тот кто еще помнит, что вообще-то не всегда, а данная практика/методология итп появилась по конкретным причинам, а сейчас контекст стал другим и она уже не так эффективна. Мораль думаю и так ясна - задавать себе простой вопрос "а почему мы делаем именно так?" и если у вас или команды нет очевидного ответа, пришло время передоговориться! А делать это всегда лучше с профессионалами, и вы знаете как нам написать! 🏆⚡🔞 PS а кто помнит свой первый ноут или вообще есть сохранившиеся раритеты - кидайте фотки, пятница ж 😎 у меня был ровер бук кажется в 2002/03! #itbp #itmegastar

Друзья, привет! Сэм на связи! Поделился мыслями о налаживании контакта бизнеса с разработчиками на канале бизнес-клуба "Атланты", резидентом которого я являюсь уже 4-й год.

Цифровизация бизнеса: как без технических знаний понять программистов и подружиться с разработкой? Рекомендации основателя группы компаний IT~BP Сэма Якушева↘️ Далеко не каждый руководитель имеет технический бэкграунд. Но для создания востребованного продукта, который принесет пользу клиенту и прибыль бизнесу, собственнику придется столкнутся с разработкой и цифровизацией. Как раз на этом этапе и кроется проблема - в сложности управления IT-отделом. ➡️ Какой тогда может быть выход? Он кроется в правильной коммуникации, партнерских отношениях между бизнесом и IT. Смотрите видео от нашего резидента, основателя группы компаний IT~BP, Сэма Якушева, где он поделился конкретными действиями, которые помогут: 🟣подружиться с разработчиками и без технических знаний грамотно контролировать их работу; 🟣 осознаннее работать вместе и сократить конфликты; 🟣 создать платформу для совместной эффективной деятельности и успеха проекта. ⬆️⬆️ Смотрите видео выше ⬆️⬆️ А затем обязательно забирайте чек-лист приемки продукта от Сэма, который поможет упростить процесс сдачи проекта и убедиться, что вам переданы все материалы в нужном объеме. И если вдруг у вас еще останутся вопросы, можете найти ответы на них на канале Сэма ➡️ перейти на канал ❓ Поделитесь, а как у вас отношения с командой разработки? Если ли сложности и как вы с ними справляетесь? #КолонкаРезидентов

Всем привет от Ильдара! FailConf сегодня в Москве, а вдруг кто-то был?! В целом конечно в узком кругу ИТ сектора надо иногда поговорить о скелетах шкафах и извлечённых уроках! Кейсы разные от бизнесовых, продуктовых, про команду, найм, партнерства или просто выбор стека и методологии! Любопытное наблюдения - файлы из Долины всегда более драматичные, наш бизнес как будто с большей улыбкой все воспринимает. Или те кто больно обжегся просто у нас про это не говорят?! Как бы то не было всем отличных выходных!! #itbp #itmegastar

Все когда-то уже было, или не все?! 🧐 Вот такая заметка была в журнале Крокодил еще 64 года! Просто немного философии от Ильдара о "раздутых командах"...будет много кавычек 🤫 ведь об этом не принято говорить.. Зацепило на днях это фото, и подумалось, что часто руководители наращивают вокруг себя/процесса/отдела/бизнес направления целую структуру иногда просто создавая его "по учебнику", иногда чтобы иметь "защиту" или мб просто на кого можно будет потом все "свалить"? И получается когда объема работ на условно 20 часов в месяц, появляется фултайм сотрудник на 160, но его же надо мотивировать - вот ему еще руководитель, тоже на фултайм итд. А в итоге проект не летит и вот за это обидно. Как сказал один мой хороший товарищ занимающий большую позицию в телекоме, почти дословно: "...а у нас как, ИТшники приходят, работают над новой инициативой, полгода что-то бурлит...а потом тишина...ИТшники уходят, и только связисты остаются...". Давайте делать ИТ понятнее для бизнеса, а бизнес - не бойтесь идти в разговор с ИТ, хватит уже стереотипов. Если вы не осваиваете бюджет, а реально хотите двигать проекты - бизнесу и ИТ по пути. И вы знаете кого позвать 😎, чтобы посмотрели на вас со стороны, аудит/обучение итд - пишите в коментах, если есть интерес продолжить диалог приватно! #itbp #itMegastar

Все когда-то уже было, или не все?! 🧐 Вот такая заметка была в журнале Крокодил еще 64 года! Просто немного философии от Ильдара о "раздутых командах"...будет много кавычек 🤫 ведь об этом не принято говорить.. Зацепило на днях это фото, и подумалось, что часто руководители наращивают вокруг себя/процесса/отдела/бизнес направления целую структуру иногда просто создавая его "по учебнику", иногда чтобы иметь "защиту" или мб просто на кого можно будет потом все "свалить"? И получается когда объема работ на условно 20 часов в месяц, появляется фултайм сотрудник на 160, но его же надо мотивировать - вот ему еще руководитель, тоже на фултайм итд. А в итоге проект не летит и вот за это обидно. Как сказал один мой хороший товарищ занимающий большую позицию в телекоме, почти дословно: "...а у нас как, ИТшники приходят, работают над новой инициативой, полгода что-то бурлит...а потом тишина...ИТшники уходят, и только связисты остаются...". Давайте делать ИТ понятнее для бизнеса, а бизнес - не бойтесь идти в разговор с ИТ, хватит уже стереотипов. Если вы не осваиваете бюджет, а реально хотите двигать проекты - бизнесу и ИТ по пути. И вы знаете кого позвать 😎, чтобы посмотрели на вас со стороны, аудит/обучение итд - пишите в коментах, если есть интерес продолжить диалог приватно! #itbp #itMegastar

История выбора одного поставщика. Ранее в сериале... см.выше 👆 >>>> Часть II <<<< Этап третий, корректировка. Член совета директоров провел несколько интервью с подрядчиками, в процессе их он получил новую для себя информацию. Профессионалы объяснили ему на какую из систем компании лучше всего переходить и описали свои предложения по путям перехода. ✅ Член совета директоров делится своими знаниями с советом директоров и они все вместе принимают решение, нужно ли изменить требования к проекту. Если да, то как именно. ✅ После того, как выбрали систему для перехода и выбрали подходящий для компании процесс перехода, члены совета директоров формируют систему критериев оценки предложения подрядчика. Например: цена, сроки, похожие проекты и т.д. Этап четвертый, запрос итоговых предложений. ☑ Оставшимся после второго этапа подрядчикам оглашаются итоговые требования. Член совета директоров смотрит, как подрядчики реагируют на изменения требований и как они ведут диалог. ☑ Для принятия решения должно быть не менее 3 подрядчиков. Этап пятый, решающий. ✅ Со всех подрядчиков получили КП и составили таблицу по критериям отбора. На основании данных в таблице и субъективных ощущений члена совета директоров принимается решение о выборе подрядчика. ✅ Субъективные ощущения члена совета директоров должны проверяться и обсуждаться. То есть нужно обсуждать с другими членами директоров, что нравится либо не нравится в том либо ином подрядчике. ✅ Субъективные ощущения не должны отвергаться. Все же ответственному члену совета директоров предстоит с выбранным подрядчиком провести непростой бизнес-проект по переходу в компании на другую 1С (или иное решение, алгоритм выбора +- работает также). На что мы НЕ рекомендуем смотреть: ❌ Рейтинги. В них участвуют далеко не все. Места покупаются. Это маркетинговый материал. ❌ Количество специалистов в штате. Многие работают арендованными командами исполнителей, сохраняя у себя только компетентное ядро команды. ❌ Возраст компании. Вообще ни на что не влияет в этом мире. Мало ли какое юридическое лицо (молодое либо старое) кто-то взял/купил. Да, есть мошенники, которые не могут пройти даже такую простую проверку. Но мы надеемся, что будут привлекаться команды, репутацию которых можно проверить. 📲💻🖥 Если вы планируете или сейчас сами находитесь в процессе выбора поставщика на какое-то ПО или думаете о "переезде" с одного ПО на другое - напишите нам, и мы пройдем этот пусть вместе с вами, что по факту только сэкономит деньги и время! До связи!!! #itbp #itMegastar

вносить изменения в типовые блоки - то все плохо, каждое обновление 1С будут приносить боль. Если подрядчик делает их отдельными модулями, которые не вносят изменения в типовые модули, то все более-менее неплохо. 6⃣ Если подрядчик не может назвать границы проекта по срокам и деньгам, а предлагает делать все итерациями, то все плохо. 1С - это система учета, зачастую там все связанно со всем, двигаться итерациями, по SCRUM и так далее - это плохая идея, которую не советует применять и сама компания 1С (у них прямо есть расписанная стандартная методика внедрения). На этом этапе член совета директоров оценивает свои субъективные ощущения: ✅ Он вообще понимал то, что говорил подрядчик? Если это был птичий язык, который не понятен, то все плохо. Если с ним общались на понятном для него языке, то уже неплохо. ✅ Нравятся ли подходы данного подрядчика члену совета директоров? Понимает ли он эти подходы? Насколько они похожи на то, что он сам привык использовать в своей области и работе? ✅ Как много нового и полезного он узнал из разговора? Была ли у подрядчика ориентация на взаимную выгоду для обоих сторон? ПРОДОЛЖЕНИЕ СЛЕДУЕТ... #itbp #itMegastar

👋 Приветствуем всем! Давно с вами не общались 😎 И вот появился повод. История выбора одного поставщика... нет, мы не сдаем своих клиентов, зато получился хороший лонгрид, выпустим в двух частях. 🚀 Ловите отличный шаблон для выбора поставщика ИТ услуг, применим для любых сложных решений. Подготовлен нашим Константином Митиным, репосты приветствуются. Если вы сами находитесь сейчас перед таким выбором, напишите нам и ITBP эксперты сделает этот процесс эффективным. >>>> ЧАСТЬ I <<<< Этап первый, подготовительный. ✅ Сформулировать критерии приемки перехода с 1С 7.7 на 1С 8.3 (или иного программного продукта/разработки итп). Необходимо дать ответ на вопрос, как совет директоров (или иной коллегиальный орган) поймет и убедится, что переход совершен и завершен. Это не должен быть какой-то формальный показатель типа «нет ошибок», «все задачи закрыты». Это те критерии, глядя на которые члены совета директоров могут сказать: «Мы это сделали». Возможно, на уровне конечных пользователей могут быть еще какие-то замечания либо запросы на доработки. Оцениваться должна именно польза для бизнеса. В целом, критерий приемки может выглядеть следующим образом: «Работа пользователей в 1С 7.7 прекращена (это можно проверить), такие-то процессы в компании (именно в компании) продолжают работать стабильно (на взгляд совета директоров)». То есть старую программу отключили, бизнес-процессы хуже работать не стали. Ожидать, что все сразу станет работать лучше, не стоит. Цель этого этапа скинуть балласт лишнего функционала и заложить фундамент для будущего роста. ✅ Выбрать члена совета директоров (или иного уполномоченного представителя), который поведет проект и будет принимать окончательное решение. Нужно понимать, что в процессы рядовых сотрудников компании будут вноситься изменения, им придется переучиваться на работу в новой программе. Будет большое сопротивление, в том числе и сопротивление политическое. У члена совета директоров должно быть достаточно авторитета, чтобы противостоять давлению нижних слоев и решать конфликты интересов. Этап второй, исследовательский. На этом этапе член совета директоров принимает участие в итоговых встречах с подрядчиках, на которых ему нужно, чтобы ему рассказали: 1⃣ На какую систему компании нужно переходить (1C ERP, 1C КА, 1С УТ) и почему. Подрядчик должен объяснить почему он рекомендует ту либо иную систему, раскрыть достоинства и недостатки систем. 2⃣ Подрядчик должен назвать стоимость выполнения работ под ключ. Возможно, подрядчик попросить сначала провести исследование процессов в компании, а потом назвать конечную цену перехода. Такое может быть, но обычно подрядчик может назвать бюджет просто опираясь на статистику тех проектов, который уже выполнял. 3⃣ Подрядчик должен рассказать о нескольких похожих на ваш проект, которые он уже успешно завершил. Имеет смысл запросить контакты, к которым можно обратиться за рекомендациями. 4⃣ Подрядчик должен рассказать план выполнения проекта по вехам. Нужно обратить внимание на наличие вех: > Обследование рабочих процессов в компании. Обычно на этом моменте не территорию компании выезжают бизнес-аналитики. Обязательно нужно получить документ с описанием имеющихся (as is) процессов по окончанию вехи. Это фиксирует результат обследования. > Моделирование работы пользователей, то есть работа тестовой группы пользователей в типовой конфигурации. Описание функциональных разрывов, то есть тех моментов, которые нужно доработать в типовой конфигурации, чтобы компания могла совершить переход. Обязательно нужно получить документ с описанием функциональных разрывов по окончанию вехи. Это фиксирует результат моделирования. > Составление плана доработок и их точная оценка. Составление плана внедрения по контурам. > Этап обучения пользователей работе в новой системе. На этом этапе подрядчик посылает своих «инструкторов», чтобы обучить пользователей перед и во время внедрения. 5⃣ Необходимо обратить внимание на технический вопрос. А именно, как потом проводить обновление

📢 Как создать систему обмена знаниями с внутренними экспертами! 🎓🌍 На связи Ильдар, работая более 18 лет с компаниями по всей России и за ее пределами мы реализовали целую серию проектов по организации систем Обмен знаниями и опытом, которые по нашим наблюдениям являются одним из ключевых факторов успешного развития компании. Многие компании уже это осознали и активно используют, ведь внутренние эксперты - это ценный ресурс, который можно эффективно задействовать для передачи знаний среди сотрудников. Это особенно видно, когда речь заходит о современных технологиях, так как общая цифровая грамотность как менеджмента так рядовых специалистов по прежнему требует развития 🤝🧠 Если согласны с этим, то ваша цель - создать систему, которая позволит выявить, упаковать и доставить знания и опыт ваших внутренних экспертов непосредственно внутри компании. Почему это так важно? 🌐 Создание системы обмена знаниями силами внутренних экспертов помогает формированию сильной и конкурентоспособной организации на рынке, способной быстро адаптироваться к изменениям и преодолевать вызовы в бизнеса и не только! Рассмотрим, что можно сделать, чтобы ваши ИТ инициативы взлетали, а не оставались в статусе вечных «долгостроев»: 1️⃣ 🎯 Идентификация внутренних экспертов: нужно найти и выделить талантливых сотрудников с экспертными знаниями и опытом, желательно готовых им делиться. 2️⃣ 📚 Создание базы знаний: Структурируйте информацию и создайте удобную платформу для обмена знаниями или воспользуйтесь готовыми решениями. 3️⃣ 📚🎓 Обучение экспертов: Развивайте навыки передачи знаний и обучения для эффективного обмена опытом. И вы знаете кто может этому научить 😉 4️⃣ 🤝 Менторинг и коучинг: «Соедините» экспертов с сотрудниками для индивидуального сопровождения и передачи знаний. 5️⃣ 📢 Внутренние мероприятия: Организуйте воркшопы, тренинги, вебинары и встречи, где эксперты смогут делиться своими знаниями со всеми заинтересованными коллегами. 6️⃣ 🏆 Оценка и признание экспертов: Поощряйте и признавайте вклад экспертов в передачу знаний для поддержания их мотивации. 7️⃣ 🤝💡 Формирование сообществ и сетей: Объедините экспертов в сообщества для обмена опытом и создания сетей связей. 8️⃣ 🔄📈 Обратная связь и улучшение: Используйте обратную связь для непрерывного совершенствования системы передачи знаний. 9️⃣ 💻🔧 Технологии и инструменты: Внедряйте современные технологии и инструменты для эффективной передачи знаний и обмена информацией. 🔟 📚🌱 Непрерывное обучение: Поддерживайте процесс непрерывного обучения, чтобы развивать и обновлять знания экспертов и систему передачи знаний. Наши специалисты всегда рады поделиться своим опытом, если интересно посмотреть подходы, которые мы предлагаем для вас - ставьте «+» в комментариях. Было полезно? Поддержите пост реакцией, мне будет приятно! 😎

Всем, привет, немного юмора для хорошего настроения в начале дня 😁 А вообще тема найма, если вы в этом не эксперт может вогнать в состояние, как у героев этого видео 😱 Выход есть: ✅ Серьёзно взвесить необходимость содержания такого сотрудника/команды в штате, ведь им надо управлять, оценивать работу, корректировать ее итд ...более того завести его в штат и потом удержать интересной работой, предложить конкурентную з/п также может быть непросто. 💡Если все сходится, но ощущения как видео остались 🧐, пригласите нашего ITBP эксперта в помощь как для составления требований к позиции, так и совместного проведения собеседования с дальнейшими рекомендациями, тут будет почасовая ставка, объем оценим персонально под вас. ✅ Все таки видите, что рисков больше - оптимальное решение для вас, это взять сразу команду или конкретного специалиста во внешний найм у нас, или аутстафинг. Всегда можно поменять, а если станет ясно, что нужен другой профиль, у вас не будет никаких проблем с увольнением и выплатами, просто берете других. Всем желаем сильных ИТ команд и их плодотворной кооперации с бизнесом, и в знаете где про это спросить, плюсуйте в комментариях или напишите про это на вотс ап по номеру +74954199328, обсудим 😉