{
    "version": "https:\/\/jsonfeed.org\/version\/1",
    "title": "Блог Сергея Копылова: заметки с тегом управление проектами",
    "_rss_description": "Блог Сергея Копылова",
    "_rss_language": "ru",
    "_itunes_email": "",
    "_itunes_categories_xml": "",
    "_itunes_image": "",
    "_itunes_explicit": "",
    "home_page_url": "https:\/\/www.blog.sergeykopylov.ru\/tags\/upravlenie-proektami\/",
    "feed_url": "https:\/\/www.blog.sergeykopylov.ru\/tags\/upravlenie-proektami\/json\/",
    "icon": "https:\/\/www.blog.sergeykopylov.ru\/user\/userpic@2x.jpg?1574324497",
    "author": {
        "name": "Сергей Копылов",
        "url": "https:\/\/www.blog.sergeykopylov.ru\/",
        "avatar": "https:\/\/www.blog.sergeykopylov.ru\/user\/userpic@2x.jpg?1574324497"
    },
    "items": [
        {
            "id": "22",
            "url": "https:\/\/www.blog.sergeykopylov.ru\/all\/kogda-ne-hochetsya-peredelyvat\/",
            "title": "Когда не хочется переделывать",
            "content_html": "<p>Часто я видел такую картину: приходит новая задача на разработку нескольких страниц, программист с желанием и усердием тратит неделю или даже месяц, и разрабатывает страницы как надо. Раздел попадает к неравнодушному тестировщику и тот возвращает работу с вопросом: а как выполнить такой-то сценарий. Это обсуждается с постановщиком задачи, с разработчиком и оказывается, что никак, а сценарий важный и нужно всё переделать. Или даже раздел презентуется заказчику, а тот: ой, мы забыли о нужном сценарии, похоже, что нужно всё переделать.<\/p>\n<p>Когда так происходит раз за разом, разработчику легко взбеситься. Он со знанием дела и с вниманием всё реализовал, а теперь это нужно выкинуть и начать по новой, обидно же! И разговоры начинают сводиться к тому, что необходимо хорошо продумать задачу с самого начала, поставить строгое техническое задание и всё такое. В итоге, этам постановки технического задания может затягиваться на месяцы, а в итоге всё одно — что-то забыли и нужно переделывать. И это нормально.<\/p>\n<p>К сожалению, когда мы разрабатываем не космический корабль с очень чёткими требованиями и многолетним сроком разработки, невозможно учесть всё на этапе проектирования. И заказчик, и менеджер, и аналитик могут пропустить важные сценарии использования. И никакого способа надёжно измерить, все ли сценарии учтены, нет.<\/p>\n<p>Кроме этого нужно действовать с другой стороны: разработчик и архитектор должны продумать, как сделать так, чтобы на подобную задачу и на её переделку тратилось мало времени. Как сделать, чтобы разработка велась не недели и месяцы, а дни и недели? Тогда первые версии будут представляться пробными, а к последующим разработчики не потеряют энтузиазма.<\/p>\n<p>Короче, разработать общие правила, шаблоны страниц, поведение отдельных блоков, разработку конфигурированием, а не программированием, не рисовать макет каждой страницы; ограничить по времени как этап проектирования, так и этап разработки.<\/p>\n",
            "date_published": "2020-02-23T18:29:26+03:00",
            "date_modified": "2020-02-23T18:29:22+03:00",
            "_date_published_rfc2822": "Sun, 23 Feb 2020 18:29:26 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "22",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        }
    ],
    "_e2_version": 3559,
    "_e2_ua_string": "E2 (v3559; Aegea)"
}