2017-10-08: заметки с РИФ-Технологии
м |
м |
||
(не показаны 3 промежуточные версии этого же участника) | |||
Строка 1: | Строка 1: | ||
− | |||
− | |||
{{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-разработка - | + | А после обеда был на интересном [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
Неделю назад был на форуме РИФ-Технологии в Ульяновске. Ленинский мемориал, 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 напиши потом, пожалуйста, как оно.