Управление разработкой *

«Какой план на неделю? Я не знаю, чем сегодня день закончится!»

«Да зачем планировать, если все равно ничего не понятно!»

Знакомо? Наверняка! Эта та реальность, в которой мы сейчас находимся. Уровень неопределенности просто зашкаливает, и горизонт планирования сокращается, в лучшем случае, до нескольких дней, а иногда и до нескольких часов.

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

Компания iSpring 20 лет разрабатывает решения для дистанционного корпоративного обучения. Клиенты находятся в 172 странах, поддержка работает в режиме 24/7 на семи языках. В месяц обрабатываем примерно 7300 обращений по всем каналам связи: по телефону, электронной почте, в чате. 

97% кейсов закрываются со статусом «Довольный клиент». Но так было не всегда: чем больше становилось клиентов, тем сильнее мы начали проседать. Особенно страдали кейсы, которые отдавались в разработку. 

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

Меня зовут Арина, я руководитель отдела технической поддержки iSpring. Расскажу, как переход к двухуровневой системе поддержки помог сократить время решения задач с трёх дней до трёх часов, снизить нагрузку на отдел и перестать дёргать разработчиков из-за лёгких задач. 

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

Какими качествами должен обладать «хороший» PM и должен ли он быть для своей команды «мамой» или «папой»? На этот вопрос во время дискуссии «Современный Project Management» проекта «Техпора» от компании *instinctools попробовали ответить приглашенные ведущие эксперты. Каждый из них прошел свой уникальный путь в IT-бизнесе и руководил большими проектами и большими командами. Мы предлагаем вам выдержки из дискуссии, которая длилась больше часа и, по признанию слушателей, оказалась очень полезной как для начинающих PM, так и для опытных менеджеров.    

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

Меня зовут Анжелика Федько, я успела поработать с базой знаний с разных сторон. Например, пока была инженером технической поддержки, занималась её наполнением, созданием новых статей и актуализацией. Когда стала тимлидом, взяла на себя уже более стратегические проекты, которые нацелены не на улучшение конкретной статьи, а на базу знаний в целом. Таким образом, за 6 лет работы с базой знаний я успела рассмотреть ее с разных сторон.

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

Привет! Меня зовут Иван Аксенов, я Ruby-разработчик в компании Домклик. Расскажу о своём подходе к анализу причин выпуска неудачных релизов.

Человек склонен совершать ошибки в любой деятельности. Иногда ошибки совсем незаметны и ни на что не влияют, иногда — неизбежны. А бывает, что они настолько глупые, что стыдно признаться в их совершении. В начале карьеры в IT я тяжело переживал каждый свой неудачный релиз, требовавший выпуска хот-фикса. Я корил себя за невнимательность, и лишь спокойствие более опытных коллег позволяло охладить голову и вернуться к нормальной работе. Со временем я стал понимать, что собственная внимательность — лишь один, и далеко не главный фактор на пути к стабильной работе системы. 

Украинские события опять разделили нашу историю на периоды «До» и «После». IT все сегодняшние пертурбации коснулось нисколько не меньше, чем другие отрасли. И если в тучные годы компании могли себе позволить некоторые послабления, то сейчас проблемы оплаты, разрыв устоявшихся связей, снижение платежеспособности заказчиков и прочие последствия вынуждают их задуматься над оптимизацией расходов на разработку.

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

Всем понятно, что чипы Тайваня и др. сейчас рулят на самом высокотехнологичном уровне, поэтому вначале я расскажу про них в РФ. Чтобы не выдвигать своего мнения, ибо оно всегда спорно, рассуждая логически ("нет абсолютной истины"), я просто буду комментировать картинки, а вы сами всё поймёте, как хотите.
Методика этой статьи очень простая – с помощью официальной и абсолютно общедоступной базы данных Роспатента по адресу http://www1.fips.ru/iiss/ я занёс в три таблицы количества регистраций ТИМС (топологий интегральных микросхем) и программ для ЭВМ (далее ПрЭВМ) https://www1.fips.ru/to-applicants/software-and-databases/ по четырём последним годам в РФ и трём последним месяцам в каждом году, в том числе и в этом нашем. А, чтобы вы мне верили и проверили, если захотите, крайне быстро всё, я скриншоты прикреплю, там кросивое часто встречается и интересное, которое, кстати, можно не только показывать, но и через оставленные контакты правообладателей на сайте продавать и покупать. Мы просто хотели сделать техноброкерский стартап «Patentstore» лет 8 назад с одновременным обучением изобретательству, научно-техническому творчеству и основам патентования и именно это делать с готовой и зарождающейся ИС.

В управлении проектами часто возникает вопрос: как лучше спланировать последовательность работ разных отделов, убедиться в отсутствии оверкапа по капасити, да и вообще понять критический путь будущего релиза? Желательно ещё и визуализировать все эти планы. Ко всему этому, часто бывает, что нужно внезапно и быстро переработать утвержденное ранее.

К нашему счастью, эту проблему решили за нас еще в конце XIX века, придумав диаграмму Ганта. Затем придумали компьютеры, а после — Интернет. И, казалось бы, какие тут еще могут остаться проблемы, но не всё так просто — ведь нельзя просто создать универсальный инструмент, который удовлетворял бы нуждам всех. 

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

Не знаю, как у вас, в большом мире программирования, а у нас, в 1С, очень распространён подход «что вижу, то и программирую». Есть более удобоваримое название: «программирование от данных». Однако, чаще всего это называют говнокод. Хотя, тут я не согласен – до говнокода ещё надо немного подтянуть.

Обычно, необходимость в программировании от данных возникает под давлением ряда обстоятельств. Например, «надо срочно» или «вотпрямщас» (процентов 90 задач в 1С). Также случается «нечего там смотреть и анализировать, денег только содрать хотите» (те же 90%, пожалуй). Сверху накладывается «да точно ничего не поменяется через 10 лет» (а чего ему меняться, 90%!). Увы и ах, пересекаем три по девяносто, и получаем решающий фактор: 90% программистов 1С по-другому просто не умеют.

Поглядим на несколько примеров и их отложенных последствий.

Привет! Меня зовут Денис Рычковский. Всю сознательную жизнь я люблю две вещи: арт и игры. С 2015 года я работаю в геймдев-индустрии, а последние 3,5 года — на позициях лида и арт-директора.

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

Позиция тимлида — желанное место для многих разработчиков в пути их профессионального становления, но так ли радужна эта работа? Большая часть задач скрыта от других участников команды, потому мнение о тимлидах и их роли бывает искажено. 

Обсудили волнующую многих тему на нашем митапе с Захаром Овчаровым (Respona front-end team-lead, Toptal senior front-end developer). Встреча прошла перед конференцией IT-People Conf в Казани и вызвала интересную дискуссию. Полная версия обсуждений в нашем видео. 

Дисклеймер от Захара: все персонажи выдуманы, все действия нереальны, автор не несет никакой ответственности за ваши действия, поэтому действуйте на свой страх и риск;) 

Внезапно для себя вместо фронтенд-разработчика я стал тимлидом. Казалось бы, ничего страшного. Но как результат — огромная куча проблем.

Я всегда считал себя уравновешенным и мотивированным человеком. Думал, что в моей жизни всё прекрасно, у меня нет проблем со здоровьем и психикой. Но однажды я понял, что не так уж все хорошо: что-то мне спать не хочется, нет аппетита и настроения. Я решил обратиться к главному источнику информации — гуглу. Это было не лучшее решение. Я выяснил, что мёртв. 

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

В прошлом году мы в АРПЭ проводили исследование рынка контрактной разработки в России. Вот как выглядела оценка рынка на тот момент: рынок маленький, 1,3 млрд ₽, но растёт. Через три года такими темпами объём рынка должен удвоиться. Ситуация резко изменилась, как это повлияет на рынок контрактной разработки?

Мы серьёзно подходим к вопросам информационной безопасности наших продуктов: бережно относимся к пользовательским данным и разрабатываем сервисы с учётом требований информационной безопасности (ИБ) и публичных стандартов по разработке безопасных приложений. К сожалению, при этом всё равно могут встречаться уязвимости, создающие риски безопасности. Этого не нужно бояться, а лучше использовать эти знания для улучшения существующих контролей безопасности и построения новых. Для этого необходим видимый, эффективный и измеряемый процесс управления уязвимостями, который мы смогли построить в Ozon, и теперь хотим поделиться опытом, советами и граблями, на которые лучше не наступать. 

Про то, как взвешивать риски в продукте с учетом бешенной турбулентности. Поделился автор telegam-канала про IT продукты Алексей Арефьев.

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

Алгоритм

Берем кого-то из лидов разработки/архитектуры, садимся и...

Привет! Я Иван Антипин, заместитель директора департамента разработки в AGIMA. За свою карьеру я поработал с десятками команд. Где-то был разработчиком, где-то тимлидом, где-то помогал извне. У меня был миллион возможностей разобраться, как люди ведут себя в коллективе. Но всё же не на все вопросы существуют четкие ответы: что такое команда, как она работает, как ей управлять. В этой статье я попробую описать те методы и подходы, которые лично мне кажутся полезными и правильными.

Компания Microsoft приостанавливает продажу товаров и услуг из-за санкций США, Евросоюза и Великобритании, так заявили представители MS в официальном блоге со ссылкой на президента компании Брэда Смита.

Есть ли в России собственный софт управления проектами на фоне остановки Microsoft продажи продуктов.

В статье рассматриваются основные российские игроки, способные импортозаместить MS Project

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

Привет, Хабр! Меня зовут Никита Пимошенко, я тимлид команды Billing API в Quadcode. Сегодня поделюсь советами и кейсами из практики, которые пригодятся начинающим тимлидам.

С ростом популярности операционных систем, растет также и необходимость в обеспечении безопасности системы. С каждым днём количество атак увеличивается, а каждое обновление несет в себе новые «дыры» в системе безопасности. Я Анастасия Худоярова, ведущий специалист по безопасной разработке в Awillix, расскажу о том, как развивалась система безопасности в Android раньше и как можно обойти некоторые ее механизмы сегодня.