Рассказываю, как наша компания адаптируется к изменениям требований при планировании проектов. Материал поможет руководителям веб-студий всегда делать проекты прибыльными. Клиенты digital-компаний смогут лучше ориентироваться на рынке услуг и понимать, в каких случаях можно все починить «по гарантии», и где лучше не экономить на незаменимом.
Привет, меня зовут Дмитрий Галатов. Я работаю старшим программистом в компании ЦВТ. Веб-разработкой занимаюсь 4 года.
Недавно с командой мы завершили проект для одного из уральских банков: разработали сервис для подачи онлайн-заявки на ипотеку. Изначально проект казался простым и понятным, но у заказчика постоянно возникали новые требования. В итоге работа значительно затянулась.
Я расскажу, как в таких случаях не подвести клиента и создать сервис, который будет решать задачи бизнеса. А также каким образом выстроить работу по проекту, чтобы не пришлось ничего переделывать.
Предлагаем сегодня побывать с нами в лаборатории по сборке гоночных автомобилей класса Formula SAE (“Формула Студент”), которая расположена внутри главного здания МГТУ им. Баумана. Автомобили собирают студенты, организовав производство как настоящий бизнес-проект. Перед командой (как все начиналось, можно почитать здесь) стоит задача не просто спроектировать машину, но и сделать презентацию мелкосерийного производства и “продать” ее жюри. Чем не защита стратегии перед инвестором? ЛАНИТ пять лет поддерживает ребят, организуя обучение. О сложностях, новизне технических решений и роли девушек в команде рассказывают сами участники.
В 1884 году Эдвин Эбботт написал рассказ «Равномир» (англ. Flatland, «Флатландия») про двухмерную реальность, населённую квадратами, окружностями и прочими геометрическими фигурами. Однако это общество было жёстко иерархическим, несмотря на кажущуюся «уравномеренность» — чем больше вершин, тем выше твой статус. Вдобавок оно сопротивлялось даже самой мысли о возможности измерений высшего порядка. На этом и выстроена канва рассказа — ведущий повествование Квадрат находится в заключении за проповедь о существовании Трёхмерного Пространства.
Ирония в том, что этот сюжет предвосхитил неприглядную сущность одной ИТ-фирмы, крайне уважаемой в своей области.
Подобная статья должна была появиться раньше, лет десять или пятнадцать назад, когда Agile только начинал внедряться в ИТ-компаниях. Сколько можно бы было избежать ошибок, проблем, конфликтов, , если бы менеджеры сразу подходили к вопросу правильно, не отвлекаясь на лишние действия …
Зато за это время накопился опыт "внедрений" Agile в разных условиях, в разных компаниях, который следует обобщить и повсеместно распространять.
Все персонажи и события являются вымышленными. Любое совпадение с реально живущими или когда-либо жившими людьми случайно.
- У нас нет пока понимания о том, сколько нам стоит каждый проект и разработка новых фичей. Часть проектов, по словам директора по денюжкам в разрезе 2 лет – убыточные, - бесстрастно объясняет СЕО.
- Это как?
- Мы инвестируем деньги в разработку стратегических продуктов и проекты. В этом смысле, мы – уникальная компания.
- Это я уже поняла, а что по себестоимости?
- С этим вопросом иди к директору по денежкам. - говорит сюзерен и машет рукой на дверь.
Аудиенция закончена.
Вопрос с оценкой себестоимости и оценкой трудозатрат для интеллектуальных продуктов является сложным (хотя, возможно только в России и только в некоторых компаниях?). Как следует рассчитывать доработки it-продуктов или работу с багами? Вернее так, этот вопрос сложный, если о нем не подумали с самого начала и разработка существует в вакууме, а не в рамках единого производственного комплекса компании.
Не секрет, что огромное количество it-компаний для учета пользуются трекерами, таймс шитами и пр., чекая количество времени на работу в том или ином проекте. Другой момент, что не все эту работу делают на регулярной основе, и не все потом используют полученные данные для анализа рентабельности разработанного продукта и сверки плановых и фактических затрат. Кроме того, хотя очевидно, что для принятия решения о разработке нового продукта предполагается подверженные цифрами исследования или экспертная оценка емкости рынка для нового продукта, не все его делают перед принятием решения о старте новой разработки.
Почти полвека я занимался Программированием и ИТ-проектами в разных странах мира. Совместная работа сплачивает ... или отдаляет людей друг от друга. Вот и я за эти годы обрёл множество знакомых и даже приятелей самых разных национальностей. (А также с некоторым, существенно меньшим числом людей мои отношения после проекта остались недружественными).
Коренные представители стран Южной Азии (японцы, корейцы, китайцы, вьетнамцы) отличаются от европейцев, американцев и индусов не только произношением, но и особым менталитетом.
Без претензий на глубокое знание национальной психологии этих народов, я хотел бы в этой истории, непосредственным участником которой я был сам, немного рассказать вам об этом.
:::
В большой немецкой фирме готовились к показу своих достижений на международной выставке CEBIT. Эта выставка в городе Ганновере просуществовала с 1996 по 2018 годы и в расцвете своих лет была настоящей Меккой компьютерщиков всего мира.
Подготовка к выставке была объявлена в фирме исключительно важным делом. Поэтому подготовленные достижения перед их отправкой в Ганновер пришёл посмотреть Самый Большой Начальник - Geschaftsführer фирмы, - высокий, молодой, источающий энергию руководитель многотысячного коллектива.
У важных начальников рабочий день расписан по минутам и всё равно его не хватает. Вот и этот просмотр был назначен на поздний вечер, когда рабочий день уже кончился.
Показывать было намечено систему интеграции трёх важных приборов. Поэтому на столе, имитирующим выставочный, располагались три прибора и ноутбук.
Вокруг больших начальников всегда трётся челядь. Отличительной особенностью челяди является способность разнюхать или предугадать, где можно попасться на глаза начальству и при возможности, напомнить о себе.
Всем привет! Я Виталий Дощенко, ньюбиз-директор AGIMA. Обычно на Хабре мы рассказываем, как работаем над цифровыми продуктами. Над мобильными приложениями, высоконагруженными системами или чат-ботами. Но только не в этот раз. В этой статье я расскажу, как Канбан-метод помог нам устранить последствия пожара. Не того пожара, где куча задач и ты ничего не успеваешь, а самого настоящего пожара, который чуть не уничтожил дом моей семьи.
Предлагаем детальный гайд по подготовке к интервью по проектированию системы ML
Что означает дизайн системы ML?
Такие навыки как машинное обучение, презентации, кодирование, статистика, вероятность, тематические исследования и прочие необходимы для успешного проведения интервью по машинному обучению. И одном из главных интервью по ML является интервью по проектированию системы.
Оно необходимо для оценки кандидата на его понимание общей картины разработки полной системы ML с учетом всех деталей. В основном кандидаты ML хорошо разбираются в технических тонкостях, но когда дело доходит до их компиляции, они не могут увидеть сложности и взаимозависимости проектирования всей системы от сбора данных до оценки и развёртывания модели и поэтому плохо справляются с интервью.
Важно в таком интервью – структурированный мыслительный процесс. Однако он требует подготовки. Заранее подготовленный гайд может очень пригодиться при ограниченном времени интервью. Гарантируем, что вы сконцентрируетесь на важном, не будете долго обсуждать одно или упускать важные темы.
Итак, гайд выглядит так:
Lead Product Designer СберМаркета Олеся Гумененко рассказывает, как поддерживать в команде настроение и рабочий ритм.
Компания может расти, её цели могут меняться. И дизайнерская команда должна не просто успевать за этим ростом, но и помогать ему. В этой статье — несколько советов, которые помогут сохранять гибкость и стабильность команды даже тогда, когда меняется её состав или количество задач в работе.
Привет! Я давно заметил, что процесс добавления нового кода в проект в большинстве команд может быть не всегда стандартизирован. Из-за этого могут возникнуть сложности с коммуникациями разработчиков как на уровне описания добавленного кода, так и понимания, какое влияние несет новый функционал на сам проект. Кроме того, команде аналитиков, разработчиков и заказчикам проекта важно иметь описание хронологии изменений проекта в читабельном виде.
Поэтому решил написать статью, в которой хотелось бы затронуть тему стандартизации процесса, используя конвенции и различные инструменты, позволяющие соблюсти правильное и понятное развитие кода проекта, что и применяется в нашей компании. Статья может быть полезна всем тем, кто ведет проекты в git.
Это статей я крупно рискую быть затоптанным армией фанатов Scrum, Kanban, XP и других методик гибкого планирования. Мне придется привести аргументы в пользу того, что мир не черно-белый, и что стандартная диаграмма Ганта тоже полезна, а в некоторых случаях даже приоритетна для менеджмента проектов в IT.
Ладно, я знаю, что оправдания и водянистые введения никому не нравятся, но этот дисклеймер нужен для того, чтобы вы обратили внимание и на альтернативный опыт.
Все персонажи и события являются вымышленными. Любое совпадение с реально живущими или когда-либо жившими людьми случайно.
- А почему вы используете в расчете КП наценку и маржу?
- Директор по операциям так сказал делать.
- Хм, а этот показатель что означает?
- Это инфляция на второй год, заложенная в стоимость продукта на следующий год.
- А к моменту подписания актов и сдаче проектов в компании есть отчет по фактическим трудозатратам и рентабельности проекта?
- Нет, а зачем?
Если упустить критику в адрес терминологического обоснования наценки и маржи для it-проектов, то следует углубиться в изучение проекта.
Для разработки новых проектов, обладающих большой зоной неизвестности и следовательно риска, а также понимая использование аджайл подхода к управлению, кажется малопонятным не только сам подход к прогнозированию трудозатрат, но и определение емкости будущего рынка и как следствие будущей выручки. Поэтому на начальном этапе чаще всего планируется требуемое время на разработку нового продукта и прогнозная стоимость, по которой этот продукт можно было бы продать текущим заказчикам.
Для тех проектов, работа по которым ведется в рамках регламента и с соблюдением рутин, кажется более реалистичным предварительная оценка и понимание стоимости проекта. Стоимость проекта для заказчика складывается из времени сотрудников, участвующих в реализации проекта, которое компания перепродает заказчику с некоторой наценкой, заложенных рисков (оцениваемых по выстроенным критериям исходя из логики и/или предыдущего опыта) и затрат, которые it-компания планирует переложить на заказчика. К последним можно отнести премиальную часть, которую после завершения сделки получит команда, налоги к уплате и т.д.
От нас, разработчиков, постоянно требуют дать оценку той или иной задаче. Зачем управленцам оценки, они вам сами расскажут. Зачем клиентам оценки — вам расскажут управленцы. Но нужны ли оценки самим разработчикам?
Вы знакомы с эффектом выпрямления сроков? Тогда вывод «оценки нужны» для вас очевиден. Если «работа занимает всё отведённое под неё время», то рефакторинг «когда-нибудь» никогда не осуществится. Чтобы его запланировать и назначить срок, нужна оценка задач.
Также важно давать оценку задачам и уметь это делать потому, что спрашивать с разработчика будут непосредственно по его оценке задачи. Оценили пессимистично — получили хлыстиком за транжирство времени. Оптимистично — получили выгорание из-за посиделок по 12 часов за экраном.
Сегодня поговорим про развилку: что делать инженеру, когда старые задачки уже нет так радуют, а куда дальше двигаться пока не понятно, но есть желание попробовать проектно-менеджерское.
Проблемы и конфликты из-за прав на знания напрямую влияют на команду. Разваливаются очень хорошие и качественные проекты — просто потому, что не были распределены права на знания или это было сделано неправильно/несправедливо. Или просто не оформлены документы на продукты интеллектуальной деятельности — на те самые знания, что возникли в процессе деятельности.
Меня зовут Кирилл Митягин, я партнер в Nevsky IP Law и занимаюсь юридической практикой уже больше 20 лет. Сегодня мы вспомним дело NGINX, чтобы на этом примере разложить по полочкам, почему разработчикам нужно оформлять и распределять права на знания между работником и работодателем.
Это дело для правообладателей программы NGINX стало «черным лебедем», как модно говорить по книге Нассима Талеба. И сегодня я превращу его для вас в серого — даже если вы ничего не будете делать после этой статьи, а просто запомните информацию. Но если вы хоть немного последуете моим советам, то будете готовы к подобной ситуации — и она для вас станет не черным или серым лебедем, а превратится в белого.
Меня зовут Дмитрий Крупенин, я руковожу продуктовой разработкой в Первой грузовой компании (ПГК). Мы (Цифровая фабрика ПГК) создаем инновационные цифровые продукты для транспортной отрасли – это сервисы для наших клиентов и внутреннего использования. Непосредственно я вместе с командой разрабатываю внутренние продукты по оптимизации управления вагонами, которых у нас много – более 100 тысяч. Нам важно, чтобы парк работал четко и на полную мощность. Разработкой продуктов «про железную дорогу и вагоны» я занимаюсь более 5 лет - работал в промышленных и логистических кампаниях, поэтому хорошо разбираюсь в вопросе и готов поделиться с вами внутренней кухней. Сегодня расскажу про то, как мы в ПГК собираем и защищаем бюджет на разработку цифровых продуктов. Своего рода шпаргалка, список хинтов и советов.
