В предыдущей статье цикла о качестве алгоритмов рекомендаций мы рассмотрели свойства, которые необходимы, чтобы рекомендации приносили пользу интернет-магазину на практике. В данной статье мы расскажем как обеспечить эти свойства на примере компонентов одного из алгоритмов.
Предлагаю продолжить анализ применимости подходов в машиностроении к ИТ. С первой частью можно ознакомиться по ссылке.
В первой части я сравнивал схему производственного цикла в машиностроении и цикл разработки программного обеспечения. На мой взгляд, процессы с точки зрения “управления” имеют очень много общего. Делюсь опытом планирования, который мне удалось подсмотреть, работая на “остатках” Информационно Вычислительного Центра (ИВЦ). На старте моей карьеры в ИТ численность персонала ИВЦ уже была гораздо меньше, чем в лучшие годы, и при этом постоянно сокращалась. Отчасти это можно объяснить тем, что ЕС-ЭВМ на тот момент серьезно устарели. При этом со временем ко мне пришло осознание того, что вся теория, которая была проработана еще во времена СССР, актуальна до сих пор, ведь основные принципы не изменились. Изменился только инструментарий.
Приветствую всех читателей Хабра!
Меня зовут Константин, занимаюсь разработкой ПО, в компании «Автомакон». На данный момент работаю на проекте для «ВкусВилл».
Занимаясь разработкой программного обеспечения, очень часто сталкиваюсь с вопросами, связанными с организацией планирования. Основной мой опыт работы связан с автоматизацией на машиностроительных предприятиях, что в свою очередь накладывает определенный отпечаток на мой подход к работе.
Свой первый опыт работы в IT я получил на одном из «заводов гигантов» родом из СССР (в момент распада последнего). Мне повезло, что тогда еще работали специалисты, которые организовывали автоматизацию планирования на заводе (но об этом чуть ниже). Что в дальнейшем успешно применялось на целом ряде заводов поменьше.
В данной статье сопоставляем опыт планирования в машиностроении с организацией разработки программного обеспечения.
Есть у нас такая традиция – начальство не любить. А как быть, если начальство – ты сам? Хочется ж быть хорошим, всегда и для всех. Но получается так, увы, редко.
Как понять, что про вас думают сотрудники, как повлиять на эти мысли, что нужно делать, чтобы помимо оценок “не бесит” иногда проскакивали и “отличный руководитель!” давайте разберемся в статье. Прошу под кат.
Бюджетированию больше 100 лет. Но до сих пор многие компании сталкиваются с трудностями при составлении своих финансовых планов.
Бюджетирование не всегда приносит ту пользу, которую способно. От него можно получать больше пользы, если немного его перестроить. И это касается и небольших предприятий, и огромных корпораций.
В этой публикации мы рассмотрим основные проблемы бюджетирования, в том числе с помощью различных примеров.
Один из членов команды сказал мне, что стендапы — это пустая трата времени. И я с этим согласен. А вы разве не согласны?
Компания Retail Rocket более 10-ти лет занимается системами рекомендаций в сфере электронной коммерции. Всё это время мы сталкиваемся с неочевидными свойствами алгоритмов рекомендаций, без которых системы не будут решать свои задачи. Мы выделили и описали в статье такие свойства, как: эффективность, логичность, покрытие, специфичность, охват, актуальность и мультирегиональность. Если у вас есть система рекомендаций, и вы хотите оценить ее качество, либо вы ищете критерии для выбора или разработки системы рекомендаций, то эта статья будет вам полезна.
Привет! Меня зовут Павел Ахметчанов, я руководитель направления улучшения процессов разработки. В статье расскажу про часто используемые методики оценок задач и есть ли в них ошибки. Посмотрим, как правильно ставить вопросы при оценке. Узнаем, что собой представляет время решения задач, а это далеко не очевидная вещь. Попробуем изменить свое мышление и получим рецепт для определения времени решения задач.
Если спросить любого начинающего исследователя этой темы «А зачем нам оценка?», он скажет, что постоянно задают вопрос «Когда вы выполните эту задачу?», на который и надо ответить с помощью этой оценки. А что, если сам вопрос задан неверно?
Несколько лет назад сочетание слов Delivery и Manager редко встречались вместе. Сегодня же количество таких вакансий исчисляется сотнями, и многие компании внедряют у себя такую роль.
Что это? Очередная дань моде? Или вполне четкая трансформация IT-менеджмента? Нужно ли относиться серьезно к этой роли, или через пару лет она также быстро исчезнет, как и появилась?
За ответами на все эти вопросы прошу под кат.
Кого обычно ставят тимлидом? По каким правилам и критериям происходит выбор? Как стать именно таким кандидатом, которого назначат на эту позицию?
Это и многое другое в статье. Прошу под кат.
Product Manager – держатель одного или нескольких продуктов. Он отвечает за управление продуктом от начала до конца его жизненного цикла. Продакт является связующим звеном между компанией и клиентами (клиентами могут считаться и сотрудники компании). Именно он создает продукты, которые соответствуют потребностям рынка и пользователей, или развивает существующие (в зависимости от жизненного цикла продукта).
Сколько-то лет назад считалось, что разработчик — это человек, который знает о продукте чуть ли не больше всех. Потому что он его оцифровывает. В текущих реалиях и больших компаниях это стало просто невозможно. Да и не нужно. Число факторов, которые влияют на бизнес и продукт столь велико, что в одного человека их не впихнуть, а задач становится всё больше. При этом ключевая задача разработчика не меняется. Мир становится сложнее, а задача его моделировать остаётся.
Я видела проекты, которые избавляются от узкого горлышка в лице техлида, убирают стадию технического моделирования продукта и превращают разработчика в оператора станка, печатающего код. Появляются многочисленные прослойки продуктовых и проджект-менеджеров, продуктовых аналитиков и других специалистов, которые придумывают готовые решения и спускают их исполнителям. Это работает, приносит результаты. Но если параллельно поставить две команды: одну, где тесно интегрированы продукт и техническая модель, и вторую, которая делает решения по ТЗ, — первая покажет себя эффективнее, релиз фич будет быстрее при меньшем количестве вовлечённых людей. Как этого добиться — попробуем разобраться в статье.
Привет! Я Кир Дергачёв, руководитель разработки в Нетологии. Приглашаю вас обсудить умозрительные модели команд разработки, которые нам предлагает каждая вторая конференция, и посмотреть на свою реальную команду, которая у вас есть, реальным трезвым взглядом. Также я расскажу про все этапы тимлидства и что сам понял, пройдя их и наступив на все возможные грабли суровой рабочей действительности.
Всегда мечтал управлять процессами, работать с людьми. Казалось, что я «знаю как правильно», как изменять процессы или учить ребят, чтобы они работали лучше. Хотелось помогать ребятам жить в лучшем мире. Мечта сбылась. Но, как говорится, есть нюанс.
Поговорим о том, что вас ждёт, когда вы станете руководителем.
Изучение логических ошибок помогает в развитии критического мышления, необходимого во всех сферах жизни. School of Thought проделала отличную работу, описав 24 наиболее распространенные логические ошибки.
Организация команд в IT — проблема. Недостаточно найти адекватных специалистов с релевантным опытом, хотя и с этим есть большие трудности, важно еще, чтобы они сработались и дали результат, который ожидает от них заказчик.
Мы в «Автомакон» 13 лет помогаем предприятиям России и стран СНГ автоматизировать производственные процессы, создаем технологичные проекты на базе ИИ, мобильные приложения, сайты. За последние годы особенно хорошо продвинулись в том, как улучшать внутренние процессы взаимодействия. У нас есть некоторый опыт, который может быть полезен начинающим предпринимателям, профессионалам с небольшим опытом работы в командах и всем, кто делает первые шаги в IT.
Меня зовут Александр Нуждин, я ведущий аналитик, методолог и функциональный архитектор в компании «Автомакон», принимал участие в проектах для одного из крупнейших ритейлеров России — ВкусВилл. В статье поделюсь личным опытом и наблюдениями, как найти команду из людей, которые будут «гореть» проектом и при этом не выгорать.
Во многих IT-компаниях первые кандидаты на повышение — уже работающие сотрудники, которые хорошо справляются со своими обязанностями. Однако нередко заняв менеджерскую позицию, отличный разработчик или аналитик не справляется с новой ролью. Одна из главных причин подобной ситуации — неумение и нежелание делегировать.
Иногда кажется, что самому написать кусок кода проще, чем объяснять команде, что должно получиться в итоге. Однако такой подход в корне неверен. Он приводит к затягиванию сроков, переработкам, конфликтам, выгоранию сотрудников и руководителей.
Частая проблема — задачи не делегируются вовсе. Закоренелые айтишники норовят сделать всё собственными руками. И только когда понимают, что сами не справятся, начинают делегировать. Но лучше ошибиться, делегировав задачу, чем вообще забыть про неё, не сделав этого.
Давайте разберёмся, как новоиспечённому, а иногда и опытному IT-руководителю делегировать задачи таким образом, чтобы получать нужный результат.
Большой гайд по CJM — зачем, где и как его строить
Один из элементов создания качественного продукта — получить как можно больше информации о своем пользователе. Знать его потребности, проблемы, боли, барьеры и эмоции.
Один из полезных и крутых инструментов, который помогает мне улучшать продукт — это CJM ?
CJM или Customer Journey Map — это, если по простому, карта пути клиента. Инструмент визуализации, который лучше помогает представить путь пользователя — от возникшей у пользователя потребности и поиска им информации о продукте, до покупки и пользования продуктом.
Какой карьерный рост возможен для IT project manager?
Такой вопрос я слышу в 50% случаев.
Чаще только еще более абстрактный “Я не понимаю, кем я хочу быть”.
Я обожаю профессию project и считаю ее прекрасной стартовой позицией, открывающей любые двери для карьерного роста на любые управленческие позиции.
В этой статье покажу 10 самых популярных - по моим наблюдениям - карьерных треков для вертикального и горизонтального роста.
Для ИТ - и не только, сгруппированных в зависимости от интересов и сильных сторон ПМ.
Пришло время структурировать и осмыслить очередную порцию профессионального опыта. Изложу несколько ситуаций, участником или наблюдателем которых я являлся, с позиции тимлида. Каждая по своему забавна или печальна, и надеюсь, может быть поучительна, если вы узнаете в ней какие-то мешающие вам моменты.