Русский
Русский
English
Статистика
Реклама

Реновация

Реновация интранета. Алгоритм действий

16.07.2020 12:18:27 | Автор: admin

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


Бывает, что вкомпании интранет существует давно, ноподдерживался бессистемно или временный вариант наскорую руку так иостался постоянным. Руководители именно таких компаний приходят кнам засозданием более совершенного исовременного продукта. Приходят зареновацией интранета. Это далеко непросто техподдержка, неразовые задачи или точечные улучшения. Это системное, часто достаточно масштабное, обновление.


Работы пореновации включают следующие три этапа:


  • подготовка;
  • организация бизнес-требований, аналитика, проектирование;
  • реализация плана обновления.

Этап0. Подготовка


Подготовка креновации начинается, когда собственно обновление еще нестартовало. Наэтом этапе важно проработать ичетко зафиксировать 3момента:


  • миссия ицели;
  • команда;
  • бюджет.

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


Команда проекта


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


Например, впроекте для Первой грузовой компании коммуникация трехуровневая. Менеджер проекта общается срабочей группой, науровне проектного комитета общается аккаунт-менеджер, адиректор агентства науровне управляющего комитета.


Приступая квопросу реновации, клиенту нужно определить ключевых личностей вкоманде последующим должностям.


Стратег


Идейный вдохновитель, евангелист, который знает куда изачем идти. Онидет впереди всех.


Внашей практике без такого человека проекты получали негативный сценарий: затухали, останавливались, пропускали этапы.


Менеджер проекта


Онзанимается оперативным управлением: следит заходом выполнения проекта, взаимодействует сподрядчиком, контролирует качество исроки реализации. Иногда совмещает работу сролью стратега впроцессе реновации.


IT-компетенции


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


Источник знаний


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


Владельцы разделов


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


История изпрактики


Впроекте реновации портала БайкалСи проблема сактуализацией была решена так. Заказчик завязал квартальные премии наконтенте иотсутствии жалоб. Контент актуальный есть премия. Причем распространяется это требование втом числе наруководящие должности, тем самым вБайкалСи ещё иподталкивали руководство кучастию вобщественной портальной жизни.


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


Бюджет


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


Мыпредлагаем рассматривать траты наинтранет, как такиеже траты компании навнутреннее обустройство, накофе, чай, мебель, канцелярию. Под таким углом вложения воспринимаются легче.


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


Реновация

Почему ориентация именно натри года? Как правило, таков срок жизни любого IT-проекта. Потом онтребует реновации или доработки. Меняется ибизнес, иподход, имасштаб, требования, технологии.


Если рассмотреть компанию порядка 5000сотрудников, тополучается, что 54млн. нетак много. Всего две чашки вмесяц насотрудника.


Когда определились скомандой ибюджетом, можно двигаться впроект.


Этап1. Агрегация требований


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


Вагрегации мыследуем двум принципам:


  • собирать данные навсех уровнях структуры компании;
  • применять подход персон иобстоятельств при анализе требований.

Уровни сбора требований


Общение для сбора требований охватывает всю вертикаль компании. Важно неупустить значимые ниши, неограничиваться только узкими пожеланиями руководства. Мысталкивались спроблемой, когда каждый уровень заявлял разные потребности. Топы говорили озадачах бизнеса. Это верхнеуровневые, глобальные задачи, они нераскрывают реального запроса.


Уруководителей подразделений были свои боли, страхи. Непосредственно рядовые сотрудники, для которых делается интранет, говорили орутинных проблемах.


История изпрактики 1


Сотрудники компанииN водин голос говорили, что имнужен расчет исогласование важных показателей.


Спросили упредставителей IT-блока такие функции ниводной системе нереализованы ивпланах пока нигде нестоят.


Спросили утоп-менеджмента, теответили да, это важная приоритетная задача. Зеленый свет!


Спроектировали, согласовали срабочей группой, отправили насогласование повсей компании, нопроцесс застрял наодном изруководителей, онпостоянно искал, зачто зацепиться. Тоодну мелочь поправить, тодругую. Процесс вроде нестоит, ноинеидет.


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


Мораль: нужно выявлять нетолько потребности, ноипроблемы, которые моглибы помешать реализации. Налаживайте мосты сразу, даже снедоброжелателями.


История изпрактики 2


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


Изучили пользователей, пообщались ссотрудниками, руководителями, директором попродажам, построили CJM, реализовали прототип, дизайн.


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


Итут онговорит:


Япросил сделать сайт продающим, авысделали сайт, после просмотра которого мне хочется взять трубку имгновенно позвонить!


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


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


Мораль: обязательно пообщайтесь сруководителями инепостесняйтесь задать ему глупые вопросы науточнение.


Работа сперсонами


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


  • Persons. Акцент начеловеке, кто конкретно будет пользователем. Турист хочет узнать маршрут доточки Б. Ятурист-бабушка, ятурист-девушка, которая боится ходить потемным улицам. Я сотрудника стоит напервом месте при анализе задач.
  • Jobs-to-Be-Done. Позволяет отключиться отличности ипосмотреть наобстоятельства, при которых нужна функция.
    Например:
    Когда янезнаю, как добраться доместа, ихочу узнать маршрут доточки Б
    Когда яхочу подороге увидеть все достопримечательности, ихочу узнать маршрут довточки Б
    Когда ятороплюсь, ихочу узнать самый короткий маршрут доточки Б скорее всего проще спросить упрохожих.
    Когда яэкстремально быстро хочу узнать маршрут дотравмпункта скорее япозвоню вскорую.
    Когда яплохо ориентируюсь наместности имне лучше идти поглавным улицам, чтобы несбиться смаршрута доточкиБ

История изпрактики


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


Алгоритм сбора


Сразу предупредим, что втаком процессе, как агрегация, трудно представить четкий план действий. Часто этапы живут впараллели. Реальность заставляет возвращаться содного надругой ипроходить его поновой. Вынесможете выделить потребность без небольшого интервью. Ипровести грамотное интервью позапросам без понимания потребности.


Определение ключевой явной потребности


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


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


История изпрактики


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


Как видно насхеме, невсе заявленные требования отбизнеса были нужны клиентам, ачто-то показал только опрос пользователей.


Реновация интранета. Алгоритм действия

Интервью


После определения явной потребности, нужно подготовиться ипровести глубинное интервью. Незабывая опринципах многоуровневости, подходе персон иобстоятельств.


Блок подготовки кинтервью включает:


  • Работу над особенностями персонажей иобстоятельств, вкоторых они могут находиться. Строится карта персонажей, структурируются предположения позапросам иболям каждого ключевого игрока вкарте.
  • Выдвижение гипотез обалгоритмах решения задач. При подготовке интервью многое базируется нагипотезах. Адалее впроцессе они уточняются.

Всамом интервью нужно общаться глубоко иустно. Всегда задавать вопрос Почему? Какие мотивы уименного такого решения задачи?


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


Карта пользовательского опыта


Наоснове интервью ианализа действующих систем создается карта пользовательского опыта (CJM). Карта визуализирует путь пользователя, ожидания ибарьеры наэтом пути. Глобальная цель любой карты понять вкакой момент икак сделать взаимодействие сотрудника сцифровой средой наиболее удобным, улучшить цифровое пространство.


Есть разные подходы кформированию карты, мыстроим CJM изследующих блоков:


  • Персонажи иэтапы. Они выделены напредыдущей стадии, остается ихструктурировать. Помните, что этапы вжизни невсегда последовательны.
  • Цели, барьеры, опасения, инструменты, чувства. Накаждом этапе варианты достижения цели разные. Невсегда самый простой путь доходит допользователя. Поэтому дополнительно говорим про опасения, конкретные барьеры, инструменты иидеи.
    Особое внимание уделяйте чувствам людей, которые оказываются накаждом изэтапов.
    Например. Когда выподаете заявку, могут ответить сухим Ваша заявка принята. Амогут Ваша заявка принята, мыобработаем еевтечение трех дней. Второе приятнее, да?
    Аеще лучше Втечение часа свами свяжется специалист, ответственный завашу заявку. Если торопитесь позвоните ему сейчас, вот номер. Совершенно другой подход иощущение, хотя казалосьбы мелочь.
    Это иесть чувства иощущения, накоторые стоит обращать внимание.
  • Бизнес-требования. Функции ипотребности оформляются ввиде бизнес-требований. Это уже конкретные решения, что меняем ивнедряем. Изних складывается будущая обновленная система.

История изпрактики


Для дочки АФК Система мыреализовывали процесс сдачи авансового отчета. Укомпании много торговых представителей вразных точках России, они перманентно находились вкомандировке. Возникала потребность сдавать авансовые отчеты вовремя: выслать документы, подписать убухгалтера, руководителя, провести в1С. Пока предыдущий отчет несдан, новый транш невыдается. Разумеется, было много ошибок, документы терялись, затраты накорреспонденцию росли, сотрудники были недовольны.


Мыпредложили решение состоящее издвух релизов:


  • Документация. Сотрудник заполнял форму, она уходила в1С, онподписывал сформированный документ иотправлял попочте.
  • Электронная цифровая подпись. Ненужно ждать, когда документы придут почтой/курьером, они сразу подписаны. Новый транш денег приходит быстро.

Столкнулись содной сложностью. Укомандировочных наруках были корпоративные мобильные телефоны или планшеты, небыло ноутбуков. Подписывать ЭЦП нужно было воблаке. Реализовать ЭЦП без токенов достаточно проблематично, норешение нашли. Кстати, решение используется досих пор, аэто уже почти три года.


Помимо косвенной пользы ввиде ускорения процессов, сокращения ошибок, была явная выгода ввиде экономии накурьерской доставке. Такие суммы экономии можно смело писать вбизнес-требования, сфинансовыми доводами сложно поспорить.


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


Устав проекта


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


Устав проекта включает:


  • Поименной состав команды. Важно, чтобы люди чувствовали ответственность исвязь спроектом.
  • Органы управления. Зоны ответственности иматрица принятия решений нас часто выручает.
  • Схема выпуска релизов.
  • Метрики эффективности, которые нужно начинать считать сразу.

Дорожная карта проекта


Включает:


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

Мы, как правило, ведем еевGoogle Docs. Это достаточно простой изнакомый инструмент, нетратим ресурсы ивремя навнедрение новой специальной системы.


Зачем нужна карта?


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


Дорожная карта
Дорожная карта

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


Вспомогательные сущности


Дорожная карта иустав проекта неотъемлемые документы при реновации. Ноесть идополнительные эффективные помощники.


Карта экосистемы компании


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


Например, вПГК уменеджерского звена есть иSAP иCRM для работы сосвоими клиентами, нонашлось место так называемому Интерфейсу менеджера для работы склиентами вличном кабинете.


Схема архитектуры нового решения


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


История изпрактики


Реновация интранета. Алгоритм действия
Старая архитектура

Реновация интранета. Алгоритм действия
Новая архитектура

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


Этап2. Процесс переезда


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


При выборе поэтапного переезда важно предусмотреть два момента:


  • Сквозная авторизация пользователю достаточно авторизоваться вкорпоративной системе учета (AD) ионавтоматически может перейти влюбую версию интранета без лишнего ввода логина ипароля накаждой изплощадок.
  • Перекрестное меню меню, объединяющее разделы нового истарого портала.

Потоки


Сам переезд мыпредлагаем делать внесколько потоков.


  1. Старый портал пока еще поддерживать минимальными средствами.
  2. Новый интранет:
    • Перенос простых функций asis, они нетребуют переработки. Просто вних добавлен новый дизайн иконтент.
    • Старт полного цикла реализации каждой функции вотдельности.
    • Разработка мобильного приложения, так как оно несколько отличается технологически.
    • Техподдержка идоработка задач избэклога.


Определение типовой схемы релиза


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


  • Взаиморасчеты сподрядчиком (Fix-price, Time&Material или Retainer). Проговорить отчетность иреперные точки, необходимые ипринципиальные для закрытия этапов работ.
  • Трекеры задач, состав ипериодичность отчетности, документальная фиксация задач. Здесьже сразу решить, чья сторона будет вести отчетность изадачи.
  • Архитектура серверов, зоны ответственности, кто осуществляет накат обновлений, доступы. Есть разные требования, ккому-то надо приезжать иработать наместе.
  • Среда разработки, схема работы изоны ответственности всистеме контроля версий.
  • Технические требования (платформы, ОС, разрешения ит.д.).

История изпрактики


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


Интеграции


Интранет редко является самостоятельной единицей вIT-системе, несвязанной состальными внутренними инструментами клиента. Поэтому когда речь заходит ореновации, затрагиваются ивопросы текущей интеграции площадки вэкосистему компании.


Нас часто спрашивают, надоли менять интеграцию. Если все работает иработа устраиваетто, нерекомендуем еёломать.


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


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


Бэклог


Бэклог реестр всех требований, дополнений кним, выявленных наэтапе агрегации или внедрения. Ведение бэклога это аксиома для любого проекта. Иинтранета тем более, так как задачи ипотребности сотрудников меняются, обновляются. Впроцессе переезда появляются новые хотелки.


Ведение бэклога можно реализовать вдвух форматах:


  • Закрытый через форму подачи предложений.
  • Открытый сотображением краткого статуса иобратной связью. Это высший пилотаж сбольшой ответственностью, так как состояние бэклога будет навиду упользователей истанет для них показателем внимательного отношения команды проекта кзаявленным новшествам.

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


Анонсы


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


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


Завершение


Чтоже делает реновацию успешной? Истоитли игра свеч, раз выходит сложно имасштабно? Реновация интранета это долгосрочная инвестиция. Икак это характерно для подобных вложений, результаты иприбыль они недают мгновенно. Подобные инвестиции должны приобрести накопительный эффект, который становится заметным лишь через 1,5-2 года работы проекта.


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


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

Подробнее..

Recovery mode Волны московской реновации

27.08.2020 14:07:16 | Автор: admin


Доброго времени суток дорогие читатели хабра, 12 августа 2020 года были опубликованы этапы переезда по программе реновации (ознакомиться можно здесь) и мне стало интересно, а как это будет выглядеть, если эти этапы визуализировать. Тут нужно уточнить, что я никак ни связан с правительством Москвы, но являюсь счастливым обладателем квартиры в доме под реновацию, поэтому мне было интересно посмотреть, может даже с некоторой точностью предположить, куда возможно будет двигаться волна реновации в моём случае (а может быть и в вашем, если вас дорогой читатель это заинтересует). Конечно точного прогноза не получится, но хотя-бы можно будет увидеть картину под новым углом. Сразу нужно отметить, что у меня получилось не всё, что я хотел сделать, но если кому-то интересно почитать о том, как собирались данные и какие интересные моменты с этим были прошу под кат. Забегая вперёд, скажу, что пометить дома согласно волнам реновации получилось, однако не удалось отобразить на карте стартовые площадки, хотя их можно добавить вручную, ниже покажу как.


1. Введение


Вкратце о программе реновации

Программа реновации была запущена Правительством Москвы в 2017 году. Благодаря ей 350 тысяч московских семей, то есть более миллиона человек, переедут в новые квартиры с отделкой комфорткласса.


Какие дома войдут в программу, решали сами жители. По итогам голосования в программу было включено 5174 дома.


Участники получат равнозначное жилье в своем районе (далее можно прочитать здесь)


На основании приказа правительства Москвы от 12 августа 2020 г. 45/182/ПР-335/20 (прочитать можно здесь) вся программа переселения рассчитана до 2032 года и должна будет пройти в три этапа (три волны):


  • первый этап 2020 2024гг., в него вошло 930 домов, страницы 3-29 в приказе
  • второй этап 2025 2028гг., в него вошло 1636 домов, страницы 30-76 в приказе
  • третий этап 2029 2032гг., в него вошло 1809 домов, страницы 77-128 в приказе
  • без определённого этапа (этапы должны будут определиться до конца 1 квартала 2021г.) 688 домов, страницы 129-148 в приказе

2. Парсинг данных


Данные я взял из этого приказа, т.к. приказ это pdf файл с таблицами, то я использовал библиотеку tabula для парсинга pdf файлов.


import pandas as pdimport numpy as npimport requestsfrom tabula import read_pdfimport jsonimport os

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


test = read_pdf('prikaz_grafikpereseleniya.pdf', pages='3', pandas_options={'header':None})

test.head()


0 1 2 3 4 5
0 No п/п АО Район NaN Адрес дома unom
1 1 ЦАО Басманный Бакунинская ул., д.49 c.4 NaN 1316
2 2 ЦАО Басманный Бакунинская ул., д.77 c.3 NaN 1327
3 3 ЦАО Басманный Балакиревский пер., д.2/26 NaN 19328
4 4 ЦАО Басманный Госпитальный Вал ул., д.3 NaN 31354


Как видно из того, что получилось спарсить, чтобы очистить данные необходимо удалить лишние колонки и строчки, что и делает функция parse_pdf_table.


def parse_pdf_table(pages, pdf_file='prikaz_grafikpereseleniya.pdf'):    df = read_pdf(pdf_file, pages=pages, pandas_options={'header':None})    # удаляем не нужные строки    df = df[~(df.iloc[:,0] == 'No п/п')]    # оставляем только нужные колонки    df = df.iloc[:,1:4]    df.columns = ['AO', 'district', 'address']    return df

Каждая волна находится в своём диапазоне страниц, парсим их и проверяем по документу, т.е. количество строк должно совпадать с тем, что есть в pdf файле. (Также сразу добавляем к данным номер волны, т.к. это пригодится в будущем)


wave_1 = parse_pdf_table('3-29') # 2020 - 2024wave_1['wave'] = 1

wave_1.shape

(930, 4)

wave_2 = parse_pdf_table('30-76') # 2025 - 2028wave_2['wave'] = 2

wave_2.shape

(1636, 4)

wave_3 = parse_pdf_table('77-128') # 2029 - 2032wave_3['wave'] = 3

wave_3.shape

(1809, 4)

unknown = parse_pdf_table('129-148')unknown['wave'] = 0

unknown.shape

(688, 4)

3. Обработка данных


Обрабатывать данные будем на пандасе (pandas), для этого соберём все волны в один датафрейм df.


df = pd.concat([wave_1, wave_2, wave_3, unknown], ignore_index=True)

Выделим своим цветом метки каждой волны.


df['marker-color'] = df['wave'].map({1:'#0ACF00',  # зеленый                                     2:'#1142AA',  # синий                                     3:'#FFFD00',  # жёлтый                                     0:'#FD0006'}) # красный

Также подпишем каждую метку в зависимости от волны.


df['iconContent'] = df['wave'].map({1:'1',                                    2:'2',                                    3:'3',                                    0:''})

В описание метки добавим адрес.


df['description'] = df['address']

Если не уточнить город Москва, то по данным, полученным из геокодера получится, что реновация началась по всей стране, да что там, во всём мире. (Даёшь реновацию во всём мире! :)



df['address'] = 'Москва, ' + df['address']

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


def geocoder(addr, key='введи свой ключ'):       url = 'https://geocode-maps.yandex.ru/1.x'    params = {'format':'json', 'apikey': key, 'geocode': addr}    response = requests.get(url, params=params)    try:        coordinates = response.json()["response"]["GeoObjectCollection"]["featureMember"][0]["GeoObject"]["Point"]["pos"]        lon, lat = coordinates.split(' ')    except:        lon, lat = 0, 0    return lon, lat

%%timedf['longitude'], df['latitude'] = zip(*df['address'].apply(geocoder))

CPU times: user 2min 11s, sys: 4.31 s, total: 2min 15sWall time: 15min 14s

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


len(df[df['longitude'] == 0])

0

Сохраним полученные данные.


df.to_csv('waves.csv')

#df = pd.read_csv('waves.csv')

4. Формирование карты волн реновации


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


def df_to_geojson(df, properties, lat='latitude', lon='longitude'):    geojson = {'type':'FeatureCollection', 'features':[]}    for _, row in df.iterrows():        feature = {'type':'Feature',                   'properties':{},                   'geometry':{'type':'Point',                               'coordinates':[]}}        feature['geometry']['coordinates'] = [row[lon],row[lat]]        for prop in properties:            feature['properties'][prop] = row[prop]        geojson['features'].append(feature)    return geojson

Т.к. меток получилось очень много, то полная карта может медленно работать на слабом ПК, поэтому я разделил данные по округам Москвы для удобства.


properties = ['marker-color', 'iconContent', 'description']if not os.path.exists('data'):    os.makedirs('data')for ao, data in df.groupby('AO'):    geojson = df_to_geojson(data, properties)    with open('data/' + ao + '.geojson', 'w') as f:        json.dump(geojson, f, indent=2) 

Полученные данные в формате .geojson я сохранил в папку data. В файле ВСЕ_ОКРУГА.geojson записаны данные по всем округам вместе.


geojson = df_to_geojson(df, properties)with open('data/ВСЕ_ОКРУГА.geojson', 'w') as f:    json.dump(geojson, f, indent=2) 


ссылка на полную карту (может работать медленно) здесь.



В целом получилось не плохо, все метки внутри границ Москвы, однако, есть и несколько ошибок, как например недалеко от Сергиева Посада Пролетарий СНТ территория (п.Вороновское), д.1 или в окрестностях Орехово-Зуево Гаражный пер. (пос.ДСК Мичуринец, п.Внуковское), д.8/КБ/Н. (Честно говоря я бы и сам не сразу понял, где это находится)


5. Что хотелось сделать, но не получилось :(


Официальный список стартовых площадок находится здесь.


Также на карту волн реновации я хотел добавить стартовые площадки, однако это не получилось сделать. Проблема даже не в том, что нормально спарсить список не удалось, это можно было бы решить, проблема в том, что геокодер не может точно определить координаты по владению, например, Шмитовский проезд, вл. 39, Мукомольный проезд, вл. 6, или где находится этот адрес район Южное Медведково, мкр. 1, 2, 3, корп. 38.


Таким образом единственный источник данных это официальная карта реновации (находится здесь), а как получить из неё координаты я не знаю, если кто знает, как получить координаты стартовых площадок, напишите пожалуйста в комментах.


Однако не всё так плохо и выход всё же есть можно добавить эти метки вручную!



Видео-инструкция о том, как это сделать есть в исходном коде проекта, а также её можно посмотреть/скачать здесь.


Выводы


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


Исходный код залит на github и скачать его можно здесь.


Спасибо за внимание.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru