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

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

Проблемы и конфликты из-за прав на знания напрямую влияют на команду. Разваливаются очень хорошие и качественные проекты — просто потому, что не были распределены права на знания или это было сделано неправильно/несправедливо. Или просто не оформлены документы на продукты интеллектуальной деятельности — на те самые знания, что возникли в процессе деятельности.

Меня зовут Кирилл Митягин, я партнер в Nevsky IP Law и занимаюсь юридической практикой уже больше 20 лет. Сегодня мы вспомним дело NGINX, чтобы на этом примере разложить по полочкам, почему разработчикам нужно оформлять и распределять права на знания между работником и работодателем.

Это дело для правообладателей программы NGINX стало «черным лебедем», как модно говорить по книге Нассима Талеба. И сегодня я превращу его для вас в серого — даже если вы ничего не будете делать после этой статьи, а просто запомните информацию. Но если вы хоть немного последуете моим советам, то будете готовы к подобной ситуации — и она для вас станет не черным или серым лебедем, а превратится в белого.

Меня зовут Дмитрий Крупенин, я руковожу продуктовой разработкой в Первой грузовой компании (ПГК). Мы (Цифровая фабрика ПГК) создаем инновационные цифровые продукты для транспортной отрасли – это сервисы для наших клиентов и внутреннего использования. Непосредственно я вместе с командой разрабатываю внутренние продукты по оптимизации управления вагонами, которых у нас много – более 100 тысяч. Нам важно, чтобы парк работал четко и на полную мощность. Разработкой продуктов «про железную дорогу и вагоны» я занимаюсь более 5 лет - работал в промышленных и логистических кампаниях, поэтому хорошо разбираюсь в вопросе и готов поделиться с вами внутренней кухней. Сегодня расскажу про то, как мы в ПГК собираем и защищаем бюджет на разработку цифровых продуктов. Своего рода шпаргалка, список хинтов и советов.

Для тех, кто не читал предыдущую статью, расскажу о сути проекта. В 2020-2021 году я участвовал в роли руководителя команды разработчиков Внедренческого центра "Раздолье" в проекте Управление продажами в международной компании на базе "1С:ERP" (ссылка на сайт 1c.ru). Проект был выбран победителем международного конкурса «1С:Проекта года» в номинации «Лучший проект с использованием технологии "Дистанционное внедрение"».

Суть проекта заключалась в переводе Заказчика с 1С:УПП на 1С:ERP. На его примере кратко опишу, какой была организационная структура и какие программы мы использовали при взаимодействии в команде и с пользователями.

Практически весь проект выполнялся удалённо. Многие сотрудники Заказчика, участвующие в проекте, в условиях карантинов и локдаунов были переведены на удалённую работу. Многие сотрудники нашей компании тоже работали удалённо, с командировками в этот период были большие проблемы. Сам Заказчик работает в режиме 24х7 и является одним из крупнейших предприятий в России по производству кофе. На начало проекта в качестве основы корпоративной системы у Заказчика была программа 1С:УПП редакции 1.2 (даже не 1.3). По завершению проекта в 2021-м перешли на ERP 2.5. К слову, когда начинали работу, в 2020-м году, когда 2.5. была ещё в бета-версии, но мы решили прислушаться к рекомендациям "Фирмы 1С" запускать новые проекты на ней, а не на 1С:ERP 2.4.

Предположим, вы создали код и передали исключительное право на него другому лицу (работодателю или по договору отчуждения). Возникает вопрос - как не нарушить права нового правообладателя? В каких пределах можно использовать код, а в каких - нельзя? 

В этой статье пойдет речь о допустимом и недопустимом использовании чужого ПО, переработке и адаптации. Разберемся с правовым регулированием и с тем, что это значит на практике.

Хотели когда-нибудь примерить на себя костюмчик успешного архитектора из мира больших бизнесов? Ну тех, кто зарабатывает на лекциях и подкастах больше, чем на основной работе. Рецепт то не особенно сложный: пара успешных проектов и кул стори в интернетах. Впахивай и впаривай! Иногда в комплекте к костюму идут одноцветные тапочки…

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

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

Меня зовут Александра Хорошкова, я менеджер проектов по коммуникациям в SuperJob, и в этой статье я хочу поделиться своими способами подготовки требований. Если их описание — обязательная часть разработки, то и путь лежит через пять стадий принятия неизбежного. Давайте рассмотрим их подробнее и разберемся, зачем нужны требования, какими они бывают, и как можно быстро и качественно их составить. 

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

Недавно натолкнулся на статью в корпоративном блоге Home Credit Bank на Хабре.

Там есть ссылка на нашу статью на Хабре, статья в свою очередь ведет на наш проект, который опубликован под лицензией GNU Affero General Public License v3.0:

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

Но Home Credit Bank естественно не обращался к нам за коммерческой версией или лицензией для данной модели.

Январь этого года был для меня не только чередой праздников, но и поводом отметить год, как мы полностью переехали на новый платежный шлюз. Для нас, как для сервиса подписки на духи, это одна из ключевых систем и если с ней есть проблемы, то это касается всех в компании. Сам переезд можно сравнить с хорошей книгой: есть экспозиция  - проблемы с прошлым сервисом, завязка как мы делали выбор между своей разработкой и готовым сервисом, развитие действия - когда мы начали работать над архитектурой и делать первые коммиты, кульминация - момент первого запуска и первые проблемы с ним и развязка, когда мы закончили миграцию всех клиентов. Звучит интересно? Тогда добро пожаловать под кат.

Как социолог в IT, я регулярно провожу исследования среди тимлидов. И часто слышу от новоиспеченных лидов, что им была бы очень полезна подготовка к их новой роли. А более опытные для прокачки софт-скиллов хотят понятную систему инструментов. Подведя некоторые итоги, я составила топ-3 самых частых трудностей:

Подозреваю, что есть инструменты, чтобы делать мою работу лучше, но я о них не знаю и не очень понимаю, где их достать;

Нелегко применять софты: быть открытым, уверенным, проявлять эмпатию.

Тяжело даются one-on-one, фидбек и общение, особенно когда надо поговорить не про работу, а про что-то еще.

То есть многие просто не знают, что делать, когда становятся тимлидами: сначала им сложно и некомфортно, у них не получается или получается не то, а ожидания бизнеса и команды не очень понятны. А потом им непонятно, как можно те самые sotf skills развивать, если каждый one-on-one отнимает массу сил. 

Меня зовут Сандра Урядова, и сегодня я хочу рассказать, как на этом пути тимлиду может помочь его собственная уязвимость, в которой, как ни парадоксально, лежит сила быть человеком. Да, иногда это очень сложно сделать, но эта сила позволит вам не только выйти из стрессового состояния, но и создать благоприятный фон в команде — вы покажете другим, что так можно: быть человеком, а не машиной.

1. Голос раскладывается на фонемы. Фонемы собираются в слова тем же решением.
2. Из собираемых данных удаляются различные клиентские данные: номера карт, кодовые слова и так далее.
3. Затем полученный поток слов снабжается пунктуацией (точками и запятыми) и заглавными буквами: это нужно для нейросетей, очень чувствительных к такому. Исправляются опечатки, корректируются термины (география).
4. И на выходе получаются текстовые диалоги, как в чате: их анализирует уже нейросеть, пытающаяся привязать смысл в реальном времени.
5. После окончания звонка тексты также анализируются нейросетями, отвечающими за сбор разных метрик по голосовой и чат-поддержке.

Чтобы не продалбывать задачи нужно следовать 47 правилам в работе и жизни… стоп. Так не работает, мы же знаем. Я решил формализовать свою систему контроля задач и описать её в пошаговом гайде – с порядком и постепенным усложнением. Хочется научиться работать как процессор? Добро пожаловать под кат.

Привет, Хабр!

Это последняя часть нашей серии статей про тестирование методов тайм-менеджмента. Первую вы найдете здесь, а вторую здесь. Сегодня мы расскажем про одну крупную систему организации времени GTD (Getting Things Done) Дэвида Аллена и про приемы из книги Максима Дорофеева «Джедайские техники». В формате теста, конечно! Как и до этого, про тестирование расскажет Анна, маркетолог и один из авторов контента Click.ru.

Привет, я Таня, QA iOS в 2ГИС. Хочу рассказать, как мы починили процесс передачи задач между командами мобильных платформ и подготовки данных. По ощущениям, до починки мы будто ехали по гравийке, а после — выехали на дорогу со свеженьким асфальтом. Поэтому я хочу поделиться нашим опытом и показать, что есть смысл улучшать даже мелкие шероховатости взаимодействия.

Статья лонгрид и занимает около 15 страниц А4, что в переводе на время может занять у вас 15-20 минут. Потому если вы решите её осилить, придётся запастись временем.

Для удобства чтения добавлено оглавление с возможностью перехода по ссылкам. Приятного чтения.

Оглавление:

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

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

Последние события подтверждают, что мы не контролируем будущее. Стабильность, к которой мы привыкли в 2015-2020 годах оказалась иллюзией. Теперь ситуация может поменяться на 180 градусов.

Репутационные и денежные риски, связанные с уязвимостями, огромны. На фоне этого понятен повышенный интерес к безопасности и стремление выстроить цикл безопасной разработки (SSDLC). Сегодня мы поговорим об одном из подходов, используемых в SSDLC, – SAST.