Управление проектами *

Привет! 

Мы решили сделать серию интервью с проектами, которые проходили или проходят акселерацию в Privacy Accelerator. Это, чтобы, как говорится, и себя показать (то есть проекты, а они у нас достойные!), и людей посмотреть - ведь на Хабре самая классная техническая аудитория, которая разбирается в нашей теме.

Сейчас в Privacy Accelerator стартует пятый набор, но мы по-прежнему на связи со всеми выпускниками прошлых лет. Некоторые из первых резидентов Privacy Accelerator опять с нами, но уже в новом формате - инкубатора. Сегодня поговорим с участником самого первого набора, осень 2020 года.

Знакомьтесь - Кирилл, основатель и  CEO проекта SelfPrivacy. Два года назад его команда была отобрана в акселератор и активно в нем поработала: проверила гипотезу, провела серию пользовательских интервью, опрос, выявила ключевые боли, сделала MVP и разработала дизайн. А еще презентовала свой проект на питчинге перед экспертами и зрителями Privacy Day 2021 в Москве. Затем продолжила работу в инкубаторе. Как проект попал в Privacy Accelerator? Как проходила работа и что было особенно ценно? Чем сейчас занимается команда и какие у нее планы?

В статье предложен радиально-кольцевой метод проектирования архитектуры области (в частности - интеграционной схемы), состоящей из нескольких информационных систем, проведены общая оценка применимости этого варианта в различных ситуациях и его сравнение с классическим «макаронным» представлением. Взгляд сугубо субъективный и прикладной. Если вдруг статья привлечет очень много профессионалов – прошу придерживаться культурных о(б)суждений 😊

Как всё началось

Началось все очень просто – в норе под землей с постановки прикладной задачи, а именно: требуется разработать интеграционную схему области, состоящей из 10 информационных систем (ИС), при этом:

1. Необходимо:

• отразить все интеграционные связи каждой из 10 ИС (интеграции возможны как с ИС области, так и с ИС смежных областей (их 8));
• понимать содержание интеграционных потоков.

Коллективу Альфа-Банка и корпоративным коммуникациям больше 30 лет. За нашу историю накопилось огромное количество систем, которые внедрялись разными командами. Отпуска мы планируем в SAP HCM, командировку оформляем в SAP АХД, кандидатов ведём в E-Staff, обучение проходим в WebTutor — список внушительный. Что это значит для сотрудника? У каждой системы свой интерфейс, и нужно разбираться, где что находится. Неудобно.

Неудобства проявлялись не так явно, когда команда собиралась в офисе. В нём проще выдать доступы, бэйджи, распечатать заявления, отнести на подпись, забрать. Но весной 2020-го, когда все ушли на удалёнку, появились пробелы в коммуникациях и процессах. При этом в пандемию мы также должны были нанимать, но без визита в HR и вовлекать в корпоративную жизнь сотрудников, работающих из дома. В статье расскажем, как мы решили эти проблемы, создав единую площадку, где можно оформить документы, начислить премию или забронировать место в коворкинге.

Материал будет больше полезен HR и руководителям.

Слово креативность слышал каждый первый работник сферы IT и маркетинга. И ладно бы слышал! Часто эту самую креативность заставляют проявлять. Что делать, если ты не очень креативный человек? Как придумать идею, если ты никогда этим не занимался?

Сегодня расскажем о паре рабочих техник. Расскажем на примере креативов для таргета, во-первых, потому, что наша компания – про рекламу, а во-вторых, потому что картинки – это наглядно и весело.

Привет, Хабр! Сегодня мы, команда Risk and Compliance компании GlowByte, хотим рассказать о большом проекте с топовым банком России, который завершили буквально месяц назад. В общей сложности история длилась более 2 лет. Речь пойдёт о внедрении новой автоматической системы управления операционными рисками (СУОР). Благодаря этому проекту наш заказчик стал первым банком, полностью выполнившим требования ЦБ РФ по положению 716-П "О требованиях к системе управления операционным риском в кредитной организации и банковской группе", вступившему в силу 1 октября 2021 года. Также банк первым перешёл на продвинутый подход к резервированию капитала по операционным рискам.

За свою 20-летнюю карьеру я успел поработать и электромонтажником, и разработчиком, и менеджером, и CTO, и даже директором по BigData в Cloud в зеленом банке. За годы успел поменять более 10 компаний и сотню проектов (недавно прям выписывал в эксельку). Не скажу, что поменять проект или компанию для меня как за "хлебушком сходить", и стресс есть абсоютно всегда. Очевидные проблемы: новые люди, новые проекты и задачи, новый офис, - и ко всему необходимо привыкать. А есть и неочевидная проблема: вам по новому проекту могут передать не всю информацию, не из-за злого умысла, а из-за отсутствия методологического подхода к передаче дел. Представляю чеклист для передачи дел по проектам.

Небольшой спойлер - речь пойдет не про прописные истины с использованием цитат из Википедии, а скорее про работу со стейкхолдерами сквозь призму моего опыта создания сложных b2b продуктов в больших компаниях. Тут будет немного рефлексии по самым базовым, казалось бы, вопросам и весьма неожиданные выводы, приправленные схемками. Всё как я люблю. Но в целом это мое мнение, поэтому готов к аргументированной дискуссии в комментах)

Раз ты читаешь эту статью, то скорее всего ты имеешь отношение к проектному или продуктовому управлению и уже не раз слышал это определение. И конечно ты знаешь, что со стейкхолдерами нужно “работать”. Но обычно никто не дает конкретику - что именно значит “работать” и с кем именно. Постараемся разобраться с этим.

Можно выделить два основных формата организационных структур - функциональную и проектную (матричную). Развитие матричных структур можно проводить в разных направлениях. Например, выбрать направление максимальной универсализации или сориентироваться на удовлетворение потребностей клиента.

В статье я описал свои размышления о том, в каком направлении потенциально может развиваться эволюция матрицы и в какую точку она может прийти.

С чрезмерным стрессом такая история: он не проходит бесследно. Усталость накапливается, и если с ней ничего не делать, самого стойкого из команды может накрыть и через год после момента где “всем надо было напрячься”.

Статья посвящена трудным/трудовым обстоятельствам работы аналитиков на проектах, которые выполняются по некому варианту «Scrum + Аналитик», эти обстоятельства являются причиной стресса. Если вы думаете, что я дам вам какие-то решения, то увы, нет. Трудности эти в обозримом будущем никуда не денутся, можете считать, что вы ходите по кругу Сансары аналитика. Знайте, что вы не одни по нему ходите, может вам психологически станет легче.

Уделите мне минутку, а я расскажу вам историю, которую наверняка вы уже не раз слышали.

Итак, некий сотрудник (пускай даже будет сотрудница) приступает к новой работе. Для простоты назовем ее Лизой. Она новичок, поэтому менеджер поручает ей для начала какую-нибудь простую и посильную задачу. Наша Лиза — хороший сотрудник, поэтому работу она выполняет качественно и в срок. Ее менеджер доволен. Ввод в должность завершен, теперь ей достаются более серьезные и сложные задания — приблизительно такие же, как и остальным сотрудникам на ее должности. Помните, Лиза хороший сотрудник! Поэтому с новыми поручениями она справляется на раз-два. Начальник снова доволен и светится как новенький пятак. Ему очевидно: Лиза — прекрасное приобретение для компании, можно вовсю нагружать ее работой — она справится.

Вы заказываете у компании разработку мобильного приложения, веб-сайта или другого проекта, полностью полагая, что готовый продукт будет принадлежать только вам.

Уверены, что это действительно так?

Могут ли разработчики удерживать или претендовать на продукт?

Если возникнут конфликты, кто будет прав и как обезопасить себя и свои права?

Об этом говорим в статье.

Эта статья предназначена для широкого круга читателей. Но прежде всего, эта статья для тех, кто занимается непосредственно веб-разработкой, а также является руководителем или заказчиком этого проекта. Если вы веб-дизайнер, вам эта статья вряд ли будет особо интересной. Она поможет тем, кто хочет развиваться в целом, понимать, как происходит процесс в целом, как разработать сайт, какие этапы необходимо пройти. 

Ниже я буду рассказывать о своем опыте. Сайтами я занимаюсь  уже порядка 15 лет, а вплотную – около 10 лет. Почему это так? Сейчас любая трансформация в организации, любые изменения в организации, так или иначе, касаются информационных систем. То есть, если мы хотим получить продажи, мы должны создать сайт. Если мы хотим повысить качества сервиса, то, скорее всего, это должно каким-то образом отображаться на сайте, например, в личном кабинете и как следствие ведет за собой создание нового сайта.

Тенденции централизации и децентрализации управления в производстве ПО противоречивы и неоднозначны. Часть компаний впервые переходит к формализованному управлению проектами разработки с помощью некоторой организационной структуры (например, в Проектного офиса) после значительного укрупнения и усложнения бизнеса, часть же успешных мировых корпораций, наоборот, стремится к максимальной децентрализации, предоставляя отдельным успешным командам высочайший уровень автономности в части процессов производства и управления. Аналогичные противоречия мы видим в эволюции ролевой модели в каждой команде разработки: от упразднения роли проектного менеджера (Scrum, MSF) с заменой на скрам-мастера до тотальной и единообразной автоматизации и формализации каждого направления в разработке ПО в каждом проекте (управление требованиями, разработка, тестирование, документирование и т.д.). Более того, в составе «гигантов IT-рынка» такие противоположенные события происходят одновременно в разных продуктовых \ географических направлениях.

Вне зависимости от того, какой подход к управлению проектами разработки с соответствующей ему ролевой моделью выбран в организации почти всегда одна из важнейших областей управления остается недостаточно осознанной – это комплексное управление рисками.

Слышала от многих разработчиков, что они не любят рабочие встречи. Говорят: "Пустая трата времени", "Митинги бесполезны", "А работать то когда?". Так вот, если у вас такие встречи, то вы явно что-то делаете не так.

Всем привет!

Меня зовут Иван Антипин, я занимаю должность технического директора в компании AGIMA. 18 и 19 августа на конференции AGIMA Partners’ Weekend я рассказывал, как мы в AGIMA управляем сроками и качеством в разработке. Я не могу поделиться своим докладом с конференции, но очень хочу поделиться с вами чек-листом и самыми важными темами из моего доклада. 

В рамках этой статьи мы бы хотели рассказать про разные способы организации команд разработки, которые онлайн-кинотеатр Национальной Медиа Группы more.tv прошел за три года: цели изменений, их плюсы и минусы и допущенные ошибки. Уверены, что для многих такой формат может быть более полезен, чем изучение теории по учебникам.

Я Саша Хрущев, технический директор IT-компании WINFOX. Рассказываю, как мы пересмотрели свой подход к тимлидству, с какими трудностями столкнулись в процессе и какие результаты это дало.

Без своевременной обратной связи не решить рабочих задач, особенно если речь о вовремя замеченных недостатков и багов: 72% работников уверены, что правильная критика поможет им работать лучше. В бизнес-книгах часто говорят о том, что сначала надо хвалить, только потом ругать, а потом снова хвалить. Однако исследования говорят, что это не работает. Разобрались, почему не стоит всегда искать плюсы в ошибках, и как же критиковать, чтобы не приходилось ни делать этого второй раз, ни извиняться за бестактные комментарии.