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

Материал из MaksWiki
Перейти к: навигация, поиск
м
м
 
(не показаны 3 промежуточные версии этого же участника)
Строка 1: Строка 1:
Неделю назад был на форуме [http://tech.rif.ru/ РИФ-Технологии] в Ульяновске. Ленинский мемориал, семь параллельных треков выступлений и большая технологическая выставка в холле. И для специалистов и для широкого круга интересующихся, включая '''школьников'''. Потому что в Ульяновске проблема: в городе 150+ компьютерных компаний, и им нужны специалисты. А школьники не видят IT-карьеры, а если видят — не подозревают о том, что она возможна в Ульяновске на мировом уровне. И IT-сообщество вместе с региональными властями и системой образования работает над этим, я про этом писал еще несколько лет назад в [[Блог:Максима Цепкова/2014-04-15: AIST и Стачка|отчете про Стачку]]. И приглашение школьников на IT-форумы — часть работы по выращиванию новых кадров.
 
 
 
{{Conf-Ref}}
 
{{Conf-Ref}}
 +
[[Файл:RIFtech-logo.jpg|right|200px]]
 +
 +
Неделю назад был на форуме [http://tech.rif.ru/ РИФ-Технологии] в Ульяновске. Ленинский мемориал, 3500 участников, семь параллельных треков выступлений и большая технологическая выставка в холле. И для специалистов и для широкого круга интересующихся, включая '''школьников'''. Потому что в Ульяновске проблема: в городе 150+ компьютерных компаний, и им нужны специалисты. А школьники не видят IT-карьеры, а если видят — не подозревают о том, что она возможна в Ульяновске на мировом уровне. И IT-сообщество вместе с региональными властями и системой образования работает над этим, я про этом писал еще несколько лет назад в [[Блог:Максима Цепкова/2014-04-15: AIST и Стачка|отчете про Стачку]]. И приглашение школьников на IT-форумы — часть работы по выращиванию новых кадров.
  
 
Я выступал на треке [http://tech.rif.ru/management Процессы и управление] с рассказом про [[Роли в проекте: как поделить поляну ответственности (ТочкаСборки-2017)|Роли в проекте]] — как проектировать разделение ответственности, адекватное особенностям проекта, какие есть типовые варианты, и как разделение ответственности описывать. Передо мной Иван Селевестров рассказывал про Agile.
 
Я выступал на треке [http://tech.rif.ru/management Процессы и управление] с рассказом про [[Роли в проекте: как поделить поляну ответственности (ТочкаСборки-2017)|Роли в проекте]] — как проектировать разделение ответственности, адекватное особенностям проекта, какие есть типовые варианты, и как разделение ответственности описывать. Передо мной Иван Селевестров рассказывал про Agile.
Строка 7: Строка 8:
 
А потом я ушел посмотреть другие секции и попал на любопытный [http://tech.rif.ru/design доклад Татьяны Субботиной] о проблемах, которые встречаются на проектах с госзаказчиком. Интересно, что рассказ был на примере реального проекта, в котором встретилось очень много грабель, которые очень больно отозвались компании-разработчике. Для меня лично все грабли — знакомые, эти проблемы достаточно часто бывают на проектах с крупным корпоративным заказчиком. А для Татьяны оказались новыми. Но, что интересно, компания Татьяны довольно давно работает на рынке госзаказов, у них — много проектов и казалось бы, грабли тоже должны быть известны — ан, нет, этот проект был у нового заказчика и оказалось, что специфика довольно велика, и в ходе проекта сталкиваешься со многими неожиданностями. Основная проблема, на мой взгляд, была в том, что у заказчика достаточно тяжелые коммуникации между подразделениями и менеджер проекта не адекватно представлял себе работу подразделений-пользователей и их проблемы — а достучаться не мог. А у них ситуацию диагностировать не получилось. Плюс они чересчур серьезно приняли тендерное задание на проект — а оказалось, что его писали за полтора года для тендера, ситуация уплыла принципиально, но переделывать документ не стали и подрядчика не предупредили — действительно, а зачем?
 
А потом я ушел посмотреть другие секции и попал на любопытный [http://tech.rif.ru/design доклад Татьяны Субботиной] о проблемах, которые встречаются на проектах с госзаказчиком. Интересно, что рассказ был на примере реального проекта, в котором встретилось очень много грабель, которые очень больно отозвались компании-разработчике. Для меня лично все грабли — знакомые, эти проблемы достаточно часто бывают на проектах с крупным корпоративным заказчиком. А для Татьяны оказались новыми. Но, что интересно, компания Татьяны довольно давно работает на рынке госзаказов, у них — много проектов и казалось бы, грабли тоже должны быть известны — ан, нет, этот проект был у нового заказчика и оказалось, что специфика довольно велика, и в ходе проекта сталкиваешься со многими неожиданностями. Основная проблема, на мой взгляд, была в том, что у заказчика достаточно тяжелые коммуникации между подразделениями и менеджер проекта не адекватно представлял себе работу подразделений-пользователей и их проблемы — а достучаться не мог. А у них ситуацию диагностировать не получилось. Плюс они чересчур серьезно приняли тендерное задание на проект — а оказалось, что его писали за полтора года для тендера, ситуация уплыла принципиально, но переделывать документ не стали и подрядчика не предупредили — действительно, а зачем?
  
А после обеда был на интересном [http://tech.rif.ru/web докладе Сергея Аверина] из Acronics «Выбор JS-фреймворка для крупного проекта». Реальная проблема для них - используемые фреймворки предъявляли чрезмерно высокие требования к разработчикам. Для них web-разработка - вспомогательна к тяжелой серверной разработке, по-сути пишется административное приложение. Которое надо не просто написать однократно, а докручивать по мере развития сервиса, и задачи - простые и относительно небольшие: добавление кнопок, отдельных параметров и конфигураций для нового функционала. А те фреймворки (EXtJS, JQuery), которые они использовали - не позволяли это делать, плюс сами приложения были на разных стеках. И они запустили масштабный проект по выбору нового фреймворка, чтобы перейти на него, переписать старые приложения и вообще использовать однородный стек. Проект вели техлиды команд, и в его процессе был практически сделан собственный фреймворк, поняв, что же именно им нужно, но при этом осознав, что развитие будет слишком дорогим. И в результате сделали композитный вариант: добавили к Angular 2.0, который как раз стал гораздо более зрелым к окончанию экспериментов, собственный диспетчер событий, обеспечивающий нужное им взаимодействие и понятность кода, и получили то, что надо. Из важных идеологических вещей отмечен TypeScript. Кстати, весной предыдущая версия доклада была на HighLoad и [https://www.youtube.com/watch?v=RRIiVh708gg есть видео].
+
А после обеда был на интересном [http://tech.rif.ru/web докладе Сергея Аверина] из Acronics «Выбор JS-фреймворка для крупного проекта». Реальная проблема для них - используемые фреймворки предъявляли чрезмерно высокие требования к разработчикам. Для них web-разработка - вспомогательная к тяжелой серверной разработке, по-сути пишется административное приложение. Которое надо не просто написать однократно, а докручивать по мере развития сервиса, и задачи - простые и относительно небольшие: добавление кнопок, отдельных параметров и конфигураций для нового функционала. А те фреймворки (ExtJS, JQuery), которые они использовали - не позволяли это делать, плюс сами приложения были на разных стеках. И они запустили масштабный проект по выбору нового фреймворка, чтобы перейти на него, переписать старые приложения и вообще использовать однородный стек. Проект вели техлиды команд, и в его процессе был практически сделан собственный фреймворк, поняв, что же именно им нужно, но при этом осознав, что развитие будет слишком дорогим. И в результате сделали композитный вариант: добавили к Angular 2.0, который как раз стал гораздо более зрелым к окончанию экспериментов, собственный диспетчер событий, обеспечивающий нужное им взаимодействие и понятность кода, и получили то, что надо. Из важных идеологических вещей отмечен TypeScript. Кстати, весной предыдущая версия доклада была на HighLoad и [https://www.youtube.com/watch?v=RRIiVh708gg есть видео].
 +
 
 +
Вообще на конференции были сильные технологические треки, и мне жалко, что не получилось послушать больше. Ну, что поделать, это - обычная проблема конференций с большим количеством треков :)
 +
 
 +
А в заключении - '''ссылки на мои посты-заметки'''.
 +
 
 +
[https://www.facebook.com/techrif/posts/2048760892020376 '''Пост'''] Забавно :) Два трека: процессы и управление и дизайн и проектирование. В перовом - рассказ о том, что ситуация в проекте меняется - и это нормально, что фиксация через артефакты - работает плохо, надо действовать через коммуникации. Об этом говорил Иван Селеверстов, говорил я в своем докладе. В треке дизайна и проектирования - рассказ Таня Субботина по опыту крупного госпроекта. И там акцент на документацию и артефакты, как способ фиксации, сожаление, что на проекте постоянные изменения требований с рефреном "власть развращает", хотя для трехлетнего проекта изменения - очевидны, и много других акцентов, связанных с нормативным процессом. Но что интересно, противоречие - только формальное, на самом деле речь идет о приближении с разных сторон к примерно одному результату, и потому ставим разные акценты - те, которые представляются важными. И многое из того, о чем рассказывает Татьяна для меня - очевидно, пройденный этап - все это надо делать. Но - в необходимом объеме, а не максимально хорошо. Просто в ситуации проекта Татьяны было естественное ограничение по ресурсам, надо было сделать все, что можешь. А мой рассказ и рассказ Ивана - из позиции многих больших корпораций, в которых как раз ресурсов не жалеют, и надо разрушить чрезмерное регулирование. Так что правда - в обоих докладах.
  
А в заключении - ссылка на мои посты-заметки...
+
[https://www.facebook.com/mtsepkov/posts/1531374286919520 '''О ведении документации'''] - с интересным обсуждением. Еще заметки с РИФ.Технологии. Все-таки разброс используемых технологий часто является большой неожиданностью. Люди в 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 напиши потом, пожалуйста, как оно.
 +
{{wl-publish: 2017-10-08 20:43:55 +0300 | MaksTsepkov }}

Текущая версия на 20:53, 8 октября 2017

О других конференциях
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 напиши потом, пожалуйста, как оно.