35 вопросов для быстрой оценки качества IT проекта
Привет, дорогие читатели! Хочу поделиться с вами моим чек-листом для проверки состояния IT проекта (преимущественно web, но адаптируется и под другие). Особенно пригодится предпринимателям и управленцам, которые попали на новый проект. После проверки вы получите результат по 100-балльной системе!
Наверное, эта книга нужна не всем и не каждому, но если вам приходится проводить групповые встречи от собраний до стратсессий (фокус в книге именно на них), то это то, что не стоит пропускать. Ниже то, что я вынес для себя и применяю в своей практике проведения стратегических сессий.
А вы пробовали общаться с продуктовой командой за пределами обычных видеоконференций?
Я написал про то, как начал проводить встречи с менеджерами банка в метаверс. В статье провожу обзорную экскурсию по мета-вселенной с картинками, делюсь историей моего становления как менеджера и перехода от дорожных карт к смыслам и ценностям. А ещё рассказываю, как заменил монолог «Прямой линии» на формат AMA (ask me anything), вдохновившись крипто-сообществом.
Мне захотелось дать ребятам больше, чем цели и KPI. Что получилось — смотрите под катом.
Нам оставили немало комментариев к статьям по подготовке к собеседованию системного аналитика (СА) о том, что примеры со сложными вопросами по SQL, REST и диаграммам — избыточны. И что СА не обязан знать, как написать код обработки запроса на Python, И даже СУБД — тоже не сфера знаний СА, как и много другое. А что же обязан знать и уметь СА? Давайте пройдемся по новому профессиональному стандарту «Системный аналитик» от Минтруда РФ и возьмем требования для грейда «джуниор СА». Вам откроется немало удивительного. Правда, есть пункт, не вызывающий сомнений: «Русский язык в объеме, необходимом для выполнения трудовой функции».
Дисклеймер: эта статья для предпринимателей и руководителей команд. Пожалуйста, учитывайте это при оценке публикации.
Часто предприниматели считают делегирование небесной маной. «Как только все процессы и задачи будут переданы команде, я «выпрыгну» из гребаной операционки, уеду в Тай и буду дистанционно управлять компанией».
В этих мечтах нет ничего зазорного.
Динамика развития межсистемных интеграций в крупных компаниях в чём-то повторяет известный закона Мура, примерно каждые 1.5-2 года в них происходит, по меньшей мере, двукратное увеличение межсистемных интеграций. По большей части это эмпирическое наблюдение, но внутренние статистики пары крупных компаний его подтверждают. Причины этого разнообразны, где-то произошла декомпозиция уже работающих ИТ-систем, где-то изменились бизнес-процессы и выяснилось, что их можно более полно автоматизировать, таким образом родились новые ИТ-решения. Список причин возникновения новых интеграций большой и для любой крупной компании, вопрос контроля интеграций, централизованных инструментов, паттернов и подходов по их реализации становится всё более актуальным.
Каждый день мы собираем больше 200 ГБ данных о клиентах Lamoda, которые листают сайт и делают заказы. Но красивые цифры про наше хранилище — это одно, а правильные выводы из данных — совсем другое.
Меня зовут Александр Айваз, я руковожу командой Data & Analytics в Lamoda Tech. И сегодня расскажу об ошибках в аналитике, которые легко совершить, глядя на данные в ретейле и e-commerce. Уверен, кому-то статья поможет иначе взглянуть на собственный продукт — или даст представление о том, с какими вопросами работают продуктовые аналитики.
Конечно, многие из этих ошибок когда-либо совершали и мы сами. В статье я постараюсь не углубляться в цифры, а расскажу о причинах на собственном примере.
Привет, Хабр! Я Владимир Хрыпун, руководитель центра компетенций по развитию BPM-систем. Если кратко, то когда у вас в компании есть бизнес-процесс регулярно повторяющиеся действия приводящие к нужным и прогнозируемым результатам, и вы хотите (или собственник бизнеса), чтобы эти результаты были лучше, потерь меньше и вообще все были счастливы и купили по ламбаргини, то вам нужна такая команда как наша. Мы помогаем частично или полностью автоматизировать бизнес-процессы компании.
Эта статья о чек-листе анализа полноты бизнес-требований для проектов цифровой трансформации.
Чем больше людей работает в процессе, тем больше будет эффект от внедрения bpm-системы. Представим, что операционный бизнес – это грузоперевозки, в бизнесе около 100 000 вагонов. У вас тысячи клиентов и сотни сотрудников. И допустим, что один из процессов – это согласование с клиентом маршрута, по которому пойдет груз. Результат: маршрут согласован, вагоны готовим под погрузку. В процессе участвует несколько отделов, выполняющих различные роли, и ежедневно сотрудники компании делают сотни действий, чтобы добиться результата – такие процессы называют сквозными, они большие, сложные, но жизненно важные для бизнеса. Экономические эффекты в таком проекте можно достичь упростив процесс, сложные или редко используемые шаги сделать понятными для сотрудников. Самый яркий пример – это “Вкусно и точка” *). Они не делают самые вкусные бургеры, зато они делают их быстро и с гарантированным уровнем качества. Сложные процессы упрощены и там, где это возможно, автоматизированы. Поэтому за 5 минут мы можем купить дешевый бургер, а компания на этом зарабатывает миллионы – все счастливы (особенно акционеры))).
О техдолге говорят довольно давно и часто. Основные тезисы — он похож на денежный долг, накапливается, мешает вести разработку, и, как правило, противопоставляется задачам от бизнеса.
Мне как разработчику не нравится сложившаяся обстановка. Поэтому попытаюсь разобраться, что подразумевают под техдолгом в сообществе, какие типы задач к этому относят, расскажу, что весь техдолг влияет на бизнес и как можно построить процессы без отдельного техдолга. В качестве подготовки я провёл небольшой опрос, на который буду периодически ссылаться.
Собственники бизнеса не считают финансовые эффекты, сотрудники саботируют, а некоторым цифровизация вообще не нужна. Собрал ошибки компаний, которые задумываются о трансформации бизнеса, и примеры, как с этим справиться.
Привет, меня зовут Анастасия, я руководитель проектов в команде разработки Ареал.
Моя ежедневная среда для управления проектами — задачник, оперативник, баг-репорт, gitlab с описаниями задач программистов, kaiten с описанием задач дизайнеров и проектировщиков. Мои коллеги сталкиваются с таким же “зоопарком” площадок, поэтому мы решили поэкспериментировать и свести управление в один инструмент — gitlab. Большинство команды знакомо с gitlab — программисты работают с кодом, проджекты ставят задачи.
Менеджер: Эта задача готова?
Разработчик: Да.
Менеджер: Давайте катить на пользователей?
Разработчик: Давайте.
Менеджер: Что‑то не вижу функциональности на продакшене?
Разработчик: Ну, нам нужно еще пару дней — пройти код‑ревью, подождать, чтобы QA протестировали, собрать и выкатить релиз в прод, сделать несколько миграций данных, и потом мы откроем фичу для пользователей.
Менеджер: Но ты же сказал, что задача готова?
Разработчик: Да.
Думаю, многие из нас были свидетелями или участниками подобного диалога. Каждая сторона считает, что задача готова, но понимание состояния готовности разительно отличается. В итоге у каждой из сторон ожидания сильно расходятся с реальностью, что негативно влияет на коммуникацию между ними и, в целом, на развитие продукта. Так, как же этого избежать?
Почему множество ИТ‑проектов проваливаются?
Для людей, кто не имел опыта работы с ИТ‑проектами всё кажется достаточно банально — обсудили объем работ, заплатили, получили проект. Однако в реальности всё происходит не так.
Привет! Меня зовут Юля Шамина, я руководитель IT-проектов в СберМаркете. Хочу поделиться нестандартным по всем меркам кейсом, как мы подготовили наши сервисы к высоким предновогодним нагрузкам за 3 месяца благодаря челленджу внутренней команды нагрузочного тестирования.
Эта статья не про успешный успех, а про то, как и зачем привлекать подрядчика, если вопросом уже занимается внутренняя команда. А ещё про страх неизвестности, мучительную настройку процессов и то, как в конце концов показать высокие результаты в сжатые сроки с минимальным количеством факапов.
Если бы можно было описать этот проект одной цитатой — «Это было смело, чертовски смело!»
А теперь по порядку. Расскажу, как мы пришли к тому, что нам понадобился подрядчик, и что вообще это за проект.
Когда коллега уходит в отпуск или увольняется — работа часто буксует или останавливается даже в большой команде. Происходит это, так как внезапно выясняется, что ушедший был «узким местом» или «критичным звеном».
Мне удалось снизить влияние этих «узких мест» и «критичных звеньев» за счёт налаживания горизонтальных связей, построения ролевой модели большой команды и ещё нескольких приёмов.
Меня зовут Татьяна Сеземина, я директор по управлению проектами Холдинга Т1.
Я вырастила команду с 40 до более чем 150 человек и не потеряла управляемости.
Сейчас расскажу, как мне удалось этого добиться.
Net Promoter Score (NPS) играет важнейшую роль, служа барометром клиентской лояльности и удовлетворенности. NPS - это не просто метрика; это компас, который направляет компании на пути к улучшению качества обслуживания и оптимизации взаимоотношений с клиентами. По сути, NPS помогает предсказать рост бизнеса и его долгосрочную устойчивость на рынке.
Эта статья предназначена для широкого круга профессионалов, включая сотрудников компаний, занимающихся маркетингом, клиентским опытом, HR и социологическими исследованиями. Если вы стремитесь понять, как улучшить взаимодействие с вашими клиентами, узнать, что заставляет их оставаться верными вашему бренду или, наоборот, уходить к конкурентам, то знание о том, как правильно измерять и интерпретировать NPS, окажется для вас бесценным. В этой статье мы погрузимся в мир NPS, рассмотрим его значение для бизнеса и узнаем, как с помощью инструментов, таких как Тестограф, эффективно проводить эти измерения.
Мы поделимся уникальными кейсами, реальными примерами использования NPS, и предоставим экспертные советы, чтобы вы могли не только оценить текущее положение ваших взаимоотношений с клиентами, но и улучшить их. Независимо от того, являетесь ли вы новичком в этой области или опытным специалистом, эта статья предоставит вам ценные знания и инструменты для роста и развития вашего бизнеса.
Сумрачная картинка: большое помещение, мало света. Стол и рядом стул, на котором сидит человек. Он работает за ноутбуком. Чувствую его усталость: он сегодня уже долго работает. Его что-то отвлекает: письмо. Электронное письмо. Он нажимает на ссылку, но ничего не появляется на экране. Всё в порядке. Но на сетевом уровне уже поселилось зло: ЧЕРВЬ!!! Спустя неделю червь выкачает данные, из-за чего компания потеряет десятки-сотни миллионов рублей.
У меня случилось очередное видение — это мой дар и моё проклятие. Я вижу то, что скоро должно произойти. У меня есть немного времени, чтобы предотвратить преступление — инцидент информационной безопасности.
Эта статья будет полезна и крута всем: узнаете, как помочь своим коллегам узнать больше об информационной безопасности в незанудной форме! На одном из мест работы я смог за пару лет повысить общий уровень знаний сотрудников в 5 раз! Меня зовут Маг Владони Миша, и теперь я занимаюсь Security Awareness в Ozon. Инциденты информационной безопасности, возникающие из-за человеческой ошибки, — самые распространённые (по данным РТ). Для минимизации количества таких инцидентов необходимо повышать осведомлённость в вопросах ИБ, т.е. заниматься Security Awareness.
Привет, я Юля Зубова — руководитель отдела аналитики в диджитал-агентстве ДАЛЕЕ. Хотя написано много статей про роль аналитиков, открыты сотни вакансий и есть даже целые сформированные отделы, остались компании и команды, где их нет. Иногда приходится объяснять, зачем нужны эти специалисты.
Расскажу, какую роль играет аналитик, на каких проектах он жизненно необходим, а на каких можно обойтись и без него.
