13 главных принципов эффективной разработки государственных сайтов

13 главных принципов эффективной разработки государственных сайтов
13 главных принципов эффективной разработки государственных сайтов

Тех­но­ло­ги­че­ское под­раз­де­ле­ние пра­ви­тель­ства США опуб­ли­ко­ва­ло U.S. Digital Services Playbook  мани­фест с 13 прин­ци­па­ми раз­ра­бот­ки госу­дар­ствен­ных сай­тов и сер­ви­сов. Основ­ные кри­те­рии свя­за­ны с прин­ци­па­ми откры­той раз­ра­бот­ки, при­о­ри­те­том поль­зо­ва­тель­ских потреб­но­стей, важ­но­стью поша­го­во­го дви­же­ния и дру­ги­ми прин­ци­па­ми Agile-раз­ра­бот­ки. Мы рас­ска­жем более подроб­но о каж­дом из них.

Поделитесь этой новостью/ фото с друзьями в социальных сетях.

Критерий № 1. Понять, что нужно людям

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

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

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

Ключевые вопросы, на которые стоит обратить внимание в процессе работы над сервисом или сайтом:

  • Для каких потреб­но­стей людей создан этот сер­вис?
  • Поче­му поль­зо­ва­тель будет поль­зо­вать­ся этим сер­ви­сом?
  • Кто явля­ет­ся клю­че­вым поль­зо­ва­телем сер­ви­са?
  • Какая груп­па людей будет испы­ты­вать наи­боль­шие слож­но­сти при рабо­те с сер­ви­сом?
  • Какие мето­ды иссле­до­ва­ния были исполь­зо­ва­ны?
  • Какие клю­че­вые момен­ты были отме­че­ны в поль­зо­ва­тель­ском опы­те?
  • Как часто про­во­дят­ся тести­ро­ва­ния с реаль­ны­ми поль­зо­ва­те­ля­ми?

Критерий № 2. Продумать весь путь взаимодействия

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

Ключевые вопросы:

  • Как сей­час люди борют­ся с про­бле­мой, для реше­ния кото­рой созда­ет­ся новый сер­вис?
  • Где в этом суще­ству­ю­щем реше­нии есть боле­вые точ­ки для поль­зо­ва­те­ля?
  • Как новый сер­вис встро­ит­ся в спи­сок дру­гих услуг, кото­рые пред­ла­га­ют­ся поль­зо­ва­те­лю?
  • Какие мет­ри­ки ана­ли­за эффек­тив­но­сти сер­ви­са подой­дут луч­ше все­го?

Критерий № 3. Сделать все простым и интуитивно понятным

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

Ключевые вопросы:

  • Какие пер­во­оче­ред­ные зада­чи поль­зо­ва­тель пыта­ет­ся решить?
  • Насколь­ко слож­ным язы­ком пред­став­ле­на инфор­ма­ция?
  • На каких язы­ках будет рабо­тать сер­вис?
  • Если поль­зо­ва­тель нуж­да­ет­ся в помо­щи при исполь­зо­ва­нии услу­ги, как он смо­жет ее полу­чить?
  • Насколь­ко дизайн это­го сер­ви­са сопо­ста­вим с дизай­ном сай­тов и сер­ви­сов дру­гих госу­дар­ствен­ных услуг?

Критерий № 4. Использовать Agile- и итерационные методологии

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

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

Ключевые вопросы:

  • Сколь­ко потре­бу­ет­ся вре­ме­ни, что­бы запу­стить мини­маль­но жиз­не­спо­соб­ный про­дукт?
  • Сколь­ко вре­ме­ни потре­бу­ет­ся на уста­нов­ку и раз­вер­ты­ва­ние рабо­чей вер­сии?
  • Сколь­ко дней состав­ля­ет одна итерация/спринт?
  • Какая систе­ма кон­тро­ля вер­сии кода исполь­зу­ет­ся?
  • Какая систе­ма исполь­зу­ет­ся для отсле­жи­ва­ния оши­бок?
  • Как соби­ра­ет­ся обрат­ная связь от поль­зо­ва­те­лей и как она улуч­ша­ет рабо­ту сер­ви­са?
  • Какие потреб­но­сти и нере­шен­ные про­бле­мы поль­зо­ва­те­лей всплы­ва­ют при каж­дом эта­пе usability-теста?

Критерий № 5. Структурировать бюджет и контракты

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

Ключевые вопросы:

  • Как часто изна­чаль­но ого­во­ре­ны эта­пы раз­ра­бот­ки?
  • Како­вы пока­за­те­ли эффек­тив­но­сти, опре­де­лен­ные в дого­во­ре?

Критерий № 6. Всегда назначать ответственное лицо

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

Ключевые вопросы:

  • Кто явля­ет­ся ответ­ствен­ным лицом?
  • Какие орга­ни­за­ци­он­ные изме­не­ния были вне­се­ны для того, что­бы вла­де­лец про­дук­та имел доста­точ­ные пол­но­мо­чия для под­держ­ки про­ек­та?
  • Что необ­хо­ди­мо сде­лать вла­дель­цу про­дук­та, что­бы доба­вить или уда­лить одну из функ­ций сер­ви­са?

Критерий № 7. Приглашать только опытные команды

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

Критерий № 8. Выбрать современный набор технологий

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

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

Ключевые вопросы:

  • Какие тех­но­ло­гии и ресур­сы вы выбра­ли и поче­му?
  • Какая база дан­ных исполь­зу­ет­ся и поче­му?
  • Сколь­ко вре­ме­ни зай­мет у ново­го чле­на коман­ды уста­нов­ка ново­го про­грамм­но­го окру­же­ния для раз­ра­бот­ки?

Критерий № 9. Быть готовым к изменениям в нагрузке на сервер

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

Исполь­зо­ва­ние нена­деж­ных и уста­рев­ших реше­ний при­ве­дет толь­ко лишь к уве­ли­че­нию рас­хо­дов и затра­там вре­ме­ни на вос­ста­нов­ле­ние дан­ных в ава­рий­ных ситу­а­ци­ях.

Ключевые вопросы:

  • Какие тех­но­ло­гии и ресур­сы вы выбра­ли и поче­му?
  • Где раз­ме­щен сер­вер?
  • На каком обо­ру­до­ва­нии рабо­та­ет сер­вер?
  • Какой ресурс нагруз­ки у сер­ве­ра?
  • Что слу­чит­ся с сер­ви­сом, если рез­ко воз­рас­тет тра­фик и нагруз­ка?
  • Как был раз­ра­бо­тан сер­вис с точ­ки зре­ния мас­шта­би­ро­ва­ния?
  • Как опла­чи­ва­ет­ся хостинг еже­ми­нут­но, еже­час­но, еже­днев­но, еже­ме­сяч­но?
  • Рас­по­ло­же­ны ли ваши сер­ве­ры в раз­ных реги­о­нах?
  • При чрез­вы­чай­ной ситу­а­ции сколь­ко вре­ме­ни потре­бу­ет­ся на вос­ста­нов­ле­ние рабо­ты сер­ви­са?
  • Как часто нуж­но свя­зы­вать­ся с хостинг-про­вай­де­ром, что­бы полу­чить ресур­сы или устра­нить про­бле­му?

Критерий № 10. Автоматизировать тестирование и установку

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

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

Ключевые вопросы:

  • Какой про­цент от все­го кода тести­ру­ет­ся авто­ма­ти­че­ски?
  • Сколь­ко вре­ме­ни нуж­но, что­бы создать, про­те­сти­ро­вать и испра­вить ошиб­ку?
  • Какие инстру­мен­ты для тести­ро­ва­ния исполь­зу­ют­ся?
  • Како­ва стра­те­гия мас­шта­би­ро­ва­ния при уве­ли­че­нии тра­фи­ка?

Критерий № 11. Управлять безопасностью и конфиденциальностью

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

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

Ключевые вопросы:

  • Соби­ра­ет ли служ­ба лич­ную инфор­ма­цию от поль­зо­ва­те­ля? Как уве­дом­ля­ют об этом поль­зо­ва­те­ля?
  • Соби­ра­ет­ся ли боль­ше инфор­ма­ции, чем тре­бу­ет­ся для реше­ния постав­лен­ной перед сер­ви­сом зада­чи? Есть ли дан­ные, исполь­зо­ва­ние кото­рых не ожи­да­ет­ся поль­зо­ва­те­ля­ми?
  • Как и с кем поль­зо­ва­тель может свя­зать­ся по вопросу об уда­ле­нии или исправ­ле­нии лич­ной инфор­ма­ции о нем?
  • Будет ли инфор­ма­ция, хра­ня­ща­я­ся в систе­ме, доступ­на дру­гим поль­зо­ва­те­лям или сер­ви­сам? Каким обра­зом и как часто служ­ба про­ве­ря­ет на нали­чие уяз­ви­мо­стей?

Критерий № 12. Принимать решения на основе данных

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

Ключевые вопросы:

  • Како­вы клю­че­вые пока­за­те­ли для сер­ви­са?
  • Какие систе­мы мони­то­рин­га исполь­зу­ют­ся?
  • Что такое целе­вое сред­нее вре­мя откли­ка для вашей служ­бы?
  • Как коман­да полу­ча­ет авто­ма­ти­че­ские сиг­на­лы тре­во­ги при воз­ник­но­ве­нии инци­ден­тов?
  • Какие инстру­мен­ты исполь­зу­ют­ся для изме­ре­ния пове­де­ния поль­зо­ва­те­лей?
  • Какие инстру­мен­ты исполь­зу­ют­ся для A/B-тести­ро­ва­ния?
  • Как изме­ря­ет­ся удо­вле­тво­рен­ность ваших поль­зо­ва­те­лей?

Критерий № 13. Быть открытыми по умолчанию

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

Ключевые вопросы:

  • Как вы соби­ра­е­те обрат­ную связь от поль­зо­ва­те­лей?
  • Есть ли у вас API, какие воз­мож­но­сти он предо­став­ля­ет? Кто исполь­зу­ет его?
  • Какие ком­по­нен­ты сер­ви­са с откры­тым исход­ным кодом?
  • Какие дан­ные доступ­ны пуб­лич­но?

Сайт: U.S. Digital Services Playbook.