2017-10-08: заметки с РИФ-Технологии

Из ленты: MaksWiki — Блог:Максима Цепкова [ru]

RIFtech-logo.jpg

Неделю назад был на форуме РИФ-Технологии в Ульяновске. Ленинский мемориал, 3500 участников, семь параллельных треков выступлений и большая технологическая выставка в холле. И для специалистов и для широкого круга интересующихся, включая школьников. Потому что в Ульяновске проблема: в городе 150+ компьютерных компаний, и им нужны специалисты. А школьники не видят IT-карьеры, а если видят — не подозревают о том, что она возможна в Ульяновске на мировом уровне. И IT-сообщество вместе с региональными властями и системой образования работает над этим, я про этом писал еще несколько лет назад в отчете про Стачку. И приглашение школьников на IT-форумы — часть работы по выращиванию новых кадров.

Я выступал на треке Процессы и управление с рассказом про Роли в проекте — как проектировать разделение ответственности, адекватное особенностям проекта, какие есть типовые варианты, и как разделение ответственности описывать. Передо мной Иван Селевестров рассказывал про Agile.

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

А после обеда был на интересном докладе Сергея Аверина из Acronics «Выбор JS-фреймворка для крупного проекта». Реальная проблема для них — используемые фреймворки предъявляли чрезмерно высокие требования к разработчикам. Для них web-разработка — вспомогательная к тяжелой серверной разработке, по-сути пишется административное приложение. Которое надо не просто написать однократно, а докручивать по мере развития сервиса, и задачи — простые и относительно небольшие: добавление кнопок, отдельных параметров и конфигураций для нового функционала. А те фреймворки (ExtJS, JQuery), которые они использовали — не позволяли это делать, плюс сами приложения были на разных стеках. И они запустили масштабный проект по выбору нового фреймворка, чтобы перейти на него, переписать старые приложения и вообще использовать однородный стек. Проект вели техлиды команд, и в его процессе был практически сделан собственный фреймворк, поняв, что же именно им нужно, но при этом осознав, что развитие будет слишком дорогим. И в результате сделали композитный вариант: добавили к Angular 2.0, который как раз стал гораздо более зрелым к окончанию экспериментов, собственный диспетчер событий, обеспечивающий нужное им взаимодействие и понятность кода, и получили то, что надо. Из важных идеологических вещей отмечен TypeScript. Кстати, весной предыдущая версия доклада была на HighLoad и есть видео.

Вообще на конференции были сильные технологические треки, и мне жалко, что не получилось послушать больше. Ну, что поделать, это — обычная проблема конференций с большим количеством треков :)

А в заключении — ссылки на мои посты-заметки.

Пост Забавно :) Два трека: процессы и управление и дизайн и проектирование. В перовом — рассказ о том, что ситуация в проекте меняется — и это нормально, что фиксация через артефакты — работает плохо, надо действовать через коммуникации. Об этом говорил Иван Селеверстов, говорил я в своем докладе. В треке дизайна и проектирования — рассказ Таня Субботина по опыту крупного госпроекта. И там акцент на документацию и артефакты, как способ фиксации, сожаление, что на проекте постоянные изменения требований с рефреном «власть развращает», хотя для трехлетнего проекта изменения — очевидны, и много других акцентов, связанных с нормативным процессом. Но что интересно, противоречие — только формальное, на самом деле речь идет о приближении с разных сторон к примерно одному результату, и потому ставим разные акценты — те, которые представляются важными. И многое из того, о чем рассказывает Татьяна для меня — очевидно, пройденный этап — все это надо делать. Но — в необходимом объеме, а не максимально хорошо. Просто в ситуации проекта Татьяны было естественное ограничение по ресурсам, надо было сделать все, что можешь. А мой рассказ и рассказ Ивана — из позиции многих больших корпораций, в которых как раз ресурсов не жалеют, и надо разрушить чрезмерное регулирование. Так что правда — в обоих докладах.

О ведении документации — с интересным обсуждением. Еще заметки с РИФ.Технологии. Все-таки разброс используемых технологий часто является большой неожиданностью. Люди в 2017 году говорят, что они видят потенциал confluence и думают о том, чтобы перейти на нее с Word. Мы в CUSTIS используем MediaWiki с 2004 (confluence еще не было), и я уже лет 5 полагал, что вики используют все :) Ан, нет…

Виктор Алексеев А я как не любил вики, так и не люблю. Правда Ворд я тоже не люблю, но меньше

Максим Цепков Ну, люблю или нет — это вопрос личный. А вот технологии коллективной работы на документами — это не вопрос любви.
Асхат Уразбаев Кажется это скорее к уровню зрелости организации

Максим Цепков Ну, да. Просто, оказывается, я сильно переоценивал уровень зрелости IT-компаний, получается… Пост об этом. Ты думаешь, мир уже ого-го где, а он еще не там :(
Асхат Уразбаев Да они же разного возраста
Дмитрий Синяев А когда заказчик заставляет хотя бы Redmine (т.к. бесплатно) завести подрядчика, при этом во всю намекая на Jira — это какой уровень зрелости IT компании?
Максим Цепков Я думал, что в IT организация не может быть столь не зрелой, чтобы использовать Word и (при 10+ сотрудников или проектах больше 2 чел*недель) работать без таск-трекера. И это не вопрос зрелости организации, типа, в отрасли не принято иначе. А оказывается, все не так…
Максим Цепков Не, про wiki погорячился. Все-таки, если над документом работает 1 человек и сам документ не больше 50 страниц, то word может казаться удобнее. Но в посте речь шла о компаниях, которые больше
Arseniy Maslov Maxim Tsepkov чем не нравится Office 365 с Word Online?

Максим Цепков Office 365 — это по идеологии продвинутый GoogleDocs получается. И это — другая парадигма. Я тут ниже с Александром Горником эту тему обсуждаю, и как раз понял, что тут разница именно в парадигмах ведения документов — как есть разница в парадигмах программирования. Я предпочитаю html-wiki парадигму, и wiki люблю без wysiwyg
Александр Горник Вики? Трелло + гуглодоки =). Еще вот есть http://notion.so (только пилотно пробуем пока)

Максим Цепков Гуглодоки — это вариант для небольших автономных документов. Для сложных и долгих проектов — не вариант. А трелло — не про документацию, это ведение дел.
Александр Горник У нас 2 миллиона строк кода, 15000 тестов и 30 разработчиков. Кодовая база с 2008го.
Максим Цепков Круто! Значит вы сумели придумать, как жить именно в таком варианте. А 2м строк кода — это единый проект? Из какой области? И сколько документов (в любых единицах — штуках, килобайтах/мегабайтах)? А организацию работы где-нибудь рассказывали публично?
Александр Горник Да, это один продукт (mindbox.ru). Автоматизация маркетинга. Про организацию работы я рассказывал на аджайл дейс, в этом году буду на agileconf рассказывать. Про документы в объеме не скажу, мы стараемся долгосрочную документацию не держать, только при разработке фичи. Долгосрочное только публичное: help и developers.mindbox.ru
Максим Цепков Да, для краткосрочной googledocs вполне нормально, коллективная работа есть — в отличие от чистого word, ссылки на долгосрочную там тоже делаются. При этом долгосрочная ведется в чем-то еще, описание архитектуры там где- то тоже присутствует. Еще техни…Еще
Александр Горник Help — intercom, в нем суппорты работают и они же отвечают, developers — readme.io. Бэклог к нас в трелло, в карточках эпиков и других где нужно — ссылки на гуглодоки
Ivan Popenko Александр Горник про Notion напиши потом, пожалуйста, как оно.

Источник