Всем привет!
Меня зовут Петр и я работу в одном из крупных банков, буду рассказывать об управлении ИТ в крупной организации. Сегодня первой темой станет система KPI для управления командами. Расскажу зачем вообще нужны KPI, какой путь прошла наша компания, и в конце открою секрет какой должна быть идеальная система KPI
Смотрели фильм «Люди в чёрном»? В нём множество запоминающихся реплик и моментов, смешных и поучительных. В одной из сцен агенты попали в затруднительную ситуацию и не могли понять, какой следующий шаг в расследовании им нужно сделать. Тогда один сказал, что нужно съесть пирог, он поможет.
Меня зовут Сергей Иванов, я из «ВКонтакте для бизнеса», и сегодня предлагаю вам присесть поудобнее и съесть пирог вместе со мной.
Разработка сайта – кропотливая и трудоемкая работа, особенно, когда вы сами не знаете, что хотите получить по итогу. За техническую реализацию отвечают разработчики, дизайнеры, верстальщики и другие профильные специалисты, вам в это углубляться не стоит. Ваша задача – определиться с целями и форматом ресурса, найти референсы, проанализировать рынок ниши и т.д.
Сделали простой и понятный чек-лист, который поможет вам подготовиться к интервью с подрядчиком и объяснить, чего вы ждете от будущего сайта.
Эти советы универсальны, они никак не касаются типа разработки. Чек-лист скорее направлен на сбор информации и материалов, которые позволят создать конверсионный ресурс и отразить в нем необходимые ценности и миссии бренда. Теперь обо всем по порядку.
Сегодня я расскажу о рисковом и любопытном старте социальной сети ВашГород.ру (Кузбасс). Почему любопытном? Потому что их ноги растут из простого (но успешного) городского сайта без «денежной» корпорации за спиной. На днях я приехал в новокузнецкий офис команды. На уютной кухне офиса беседовали и пили кофе с одним из создателей проекта Антоном Поцелуйко.
Это серия историй о российских цифровых проектах. Я публикую интервью в своем блоге и телеграм-канале
После нескольких лет успешных и не очень кейсов в консалтинге, мы поняли, что пока между бизнесом и учёными нет посредника, разработки не интересны бизнесу. Мы провели первое мероприятие, которое должно было связать бизнес с наукой, а науку с консалтерской реальностью.
Дисклеймер: мы - учёные, которые занимаются консалтингом. И говорить я буду с позиций науки в первую очередь. Но мы сделали мероприятие для наших потенциальных клиентов, у нас получилось, поэтому я делюсь этим опытом. Если что-то из сказанного далее покажется вам странным или, наоборот, слишком очевидным, то буду рада фидбэку от более опытных читателей в комментах :)
Данная статья является переводом видеоролика с канала Мэтта Вулфи, который в основном посвящен теме искусственного интеллекта.
В данном видео Мэтт Вулфи обсуждает вопрос, который волнует многих: сможет ли искусственный интеллект заменить программистов? Он рассматривает текущее состояние дел и будущие возможности ИИ в программировании.
Основные моменты видео:
Разногласия в части темы замены программистов Искусственным Интеллектом.
Автоматизация задач с помощью ИИ: написание и отладка кода.
Влияние ИИ на участие разработчиков в процессе.
Необходимость наличия связующего звена между ИИ и конечными пользователями.
А также много другое и капелька теории!
Привет, уважаемые хабровчане!
В этой статье мы затронем такие важные темы, как метавселенные, должен ли разработчик окончить вуз, и нужна ли руководителю проекта собственная гадалка? Но давайте по порядку!
Мое наблюдение состоит в том, что мы — разработчики и продукты, сильно переусложняем, осознанно или нет, но всякие «„Архитектурные комитеты“, „Планирования“, „Апрувы у 50 отделов“ и деплои в 2-часовые окна, простыни текста сопровождающие простейшие фичи — это просто какой‑то бич современной разработки. Умные дяди с 20 летним опытом за плечами, с невозмутимыми лицами сутки напролет на созвонах обсасывают простейшие вещи вроде замены кнопки. Что это? Следствие усложнения программного обеспечения или засилие не тех людей не на тех местах? Или следствие входа в индустрию новичков, стремящихся простое сделать сложным?
В статье мы разберем что такое „переусложнение“, дадим ему определение и на реальных примерах разберем во что это выражается и как с этим бороться.
В предыдущей статье, где я затронул тему отмены задач, возникли оживленные дискуссии. Некоторые утверждали, что достаточно найти тим лида с "стальными яйцами", и проблемы с непонятными задачами исчезнут. Но действительно ли это так просто? И правда ли, что решение этих проблем не входит в нашу компетенцию? Как руководитель разработки, я часто вижу, как команды берут на себя задачи, которые кажутся им неправильными, тратят часы на их разъяснение и еще больше времени на доработку перед сдачей.
Может показаться, что работа по формулировке задач лежит за пределами нашей ответственности, но если мы продолжим брать непонятные задачи, для продуктовых менеджеров это будет сигналом, что все идет хорошо. Но мы знаем, что это не так. Не стоит ждать, что ситуация изменится сама по себе или кто-то внезапно решит все проблемы за нас. Пора задуматься о том, как мы можем влиять на этот процесс и сделать нашу работу более эффективной. Ведь в любом случае время на эти задачи уходит, так давайте по крайней мере потратим его с пользой.
Я ожидаю, что некоторые из вас скажут: "Всё это очевидно, просто возьми и сделай". Но давайте не будем забывать, что целые книги написаны о том, как правильно описывать требования и структурировать работу, существуют стандарты, но проблема всё ещё актуальна. Понимание того, что перед нами не простая задача, приходит с опытом в разработке, и именно поэтому я отношу её к категории средней сложности. Я старался изложить её как можно проще, но уверен, что ваши конструктивные комментарии помогут сделать изложение идеальным. Спасибо вам заранее за это.
Всем привет, вас ждет история, разрывающая стереотипы! Многие до сих пор считают, что «девушка в IT — это горе в семье». А у нас в компании есть живое опровержение этой идеи — наша руководитель отдела разработки Ксения Липская.
О том, как «девочка‑девочка» учится на айтишника, уходит и возвращается к IT‑истокам, секретах управления и увеличении скорости разработки — расскажет сама Ксения. А я всего лишь записал этот рассказ и задавал уточняющие вопросы ;)
Сегодня о том, где брать цель, как и зачем делать проекты, как прокачиваться, но при этом не париться. Очень много материалов от Ильяховых и Бюро.
Первый игровой автомат Atari Pong, был выпущен в 1972 году. Это игра для двух игроков, основанная на настольном теннисе, где каждый игрок управляет ракеткой и должен отбить мяч на другую сторону. Если игрок промахивается, соперник набирает очки. Первый кто наберет 11 очков становится победителем. Kent Steven в своей книге "The Ultimate History of Video Games" (Вся история видеоигр) описывает, что проект был отдан инженеру Aлану Алькорну (Alan Alcorn), который до этого не занимался играми и игровыми автоматами. Учитывая, что в кармане основателя Atari было немногим больше 500$, и привлечь опытных разработчиков для работы над неизвестным проектом шансы были минимальные, то Нолан Бушелл представил это как выполнение контракта для General Electric.
Алькорн превзошел ожидания на этот проект, кроме функции подсчета очков и таймера раунда, он добавил в игру разделение каждой ракетки на восемь условных сегментов, попадая в которые мяч менял траекторию движения на разные углы. Также вместо проектирования нового аркадного автомата как единого устройства, он использовал дешевый черно-белый телевизор, деревянный шкаф и ручки от газовой плиты. Кроме этого Алан перепроектировал оригинальную схему, заменил компоненты на более дешевые аналоги. Впоследствии таймер раунда был поправлен на изменение скорости шарика, это изменение добавило игре динамики, но потребовало больше памяти, из-за чего игра получила особенность, что ракетки не могли дойти до верхнего края экрана. Алькорну, ограниченному по времени, уже некогда было исправлять такое поведение и баг стал фичей, которая позволяла опытному игроку так отразить мячик, что он улетал в "мертвую зону".
Но каким бы точным и выверенным не был игровой процесс, центром игры является человек, ему свойственно ошибаться. Ошибаться в оценках, в действиях, в движения мышкой или скорости нажатия на кнопки. Когда у игрока не получается выполнить действие, которое, как он думает, было сделано правильно, он начинает ругать игру и окружение, отвлекаться и еще больше ошибаться и бросает играть. Зная эти особенности опытные дизайнеры всегда дают возможность ошибиться, но делают это так чтобы вы этого не заметили. Если игра слишком явно поддается, это раздражает даже больше, чем завышенная сложность.
Давайте разберем к каким уловкам прибегают игры, чтобы играть было интересно.
Доброго времени суток. Основываясь на своём опыте хочу представить некоторые рекомендации при разработке кодовой базы на SQL.
Данные рекомендации получены горьким опытом, так что надеюсь, они Вам помогут :)
Что интересного писали в России и за рубежом про управление проектами за прошедшую неделю? Мы прочитали все публикации с Хабра, VC (и не только) и выбрали самые крутые и полезные. Читайте аннотации, сохраняйте и применяйте!
Предлагаю продолжить анализ применимости подходов в машиностроении к ИТ. С первой частью можно ознакомиться по ссылке.
В первой части я сравнивал схему производственного цикла в машиностроении и цикл разработки программного обеспечения. На мой взгляд, процессы с точки зрения “управления” имеют очень много общего. Делюсь опытом планирования, который мне удалось подсмотреть, работая на “остатках” Информационно Вычислительного Центра (ИВЦ). На старте моей карьеры в ИТ численность персонала ИВЦ уже была гораздо меньше, чем в лучшие годы, и при этом постоянно сокращалась. Отчасти это можно объяснить тем, что ЕС-ЭВМ на тот момент серьезно устарели. При этом со временем ко мне пришло осознание того, что вся теория, которая была проработана еще во времена СССР, актуальна до сих пор, ведь основные принципы не изменились. Изменился только инструментарий.
Многие основатели и ТОП-менеджеры компаний, а также те, кто отвечают за рост продуктов в компаниях, рано или поздно задумываются о том, как вырастить бизнес, увеличить продажи, получить больше лояльных пользователей, обогнать конкурентов, как сделать бизнес и продукты внутри такими чтобы их больше покупали?
- И всегда встают резонные вопросы:
- Как делать больше за меньшее количество ресурсов?
- Как успевать и обгонять конкурентов?
- Как достигать тех целей которые ставим?
- Как кратно масштабировать бизнес и продукты?
Как правило в компаниях запускается множество проектов, которые направлены на рост бизнеса, однако более 75% не приносят тех эффектов, которые мы от них ожидали. Более того, сроки и бюджеты проектов могут растягиваться в разы. И это происходит повсеместно, и в среднем и в крупном бизнесе.
Как не умереть от рабочей рутины и не потерять фокус между десятками ежедневных задач? Как по максимуму использовать почту, календарь, мессенджер и браузер?
Читайте мини-гайд и берите на заметку!
P.S. ТОП 8 неудачных прыжков на грабли в комплекте
Парсинг сайтов — это автоматический процесс сбора и систематизации данных в интернете. Для него используют специальные программы — парсеры, которые отбирают с сайтов информацию по заданным критериям. Программа-парсер может запускаться ежедневно, а при необходимости и несколько раз в день, и через указанные сайты, которые могут включать веб-ресурсы конкурентов, онлайн-маркетплейсы или агрегаторы цен, предоставлять полученные данные.
Парсинг заменяет кропотливую ручную работу по копипастингу автоматизированным процессом.
Конспект знаковой книги про наём сотрудников.
По мнению автора, главный вопрос современного бизнеса – «кто?», а не «что?». Выигрывают, в первую очередь, те, кто поднимает планку и ориентируется только на привлечение игроков класса А – кандидатов, с вероятностью 90% имеющих шанс добиться результатов, доступных лишь для 10% подходящих кандидатов.
Для успешной реализации необходимы три составляющие:
1) Лист целей – документ с подробным описанием качеств, необходимых для выполнения определённой вами роли
2) Работающие источники привлечения подходящих кандидатов
3) Эффективный процесс отбора
В статье - подробнее каждый из пунктов...
