{
    "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:\/\/fff.works\/blog\/tags\/razrabotka\/",
    "feed_url": "https:\/\/fff.works\/blog\/tags\/razrabotka\/json\/",
    "icon": "https:\/\/fff.works\/blog\/user\/userpic@2x.jpg?1512302586",
    "author": {
        "name": "Автор блога",
        "url": "https:\/\/fff.works\/blog\/",
        "avatar": "https:\/\/fff.works\/blog\/user\/userpic@2x.jpg?1512302586"
    },
    "items": [
        {
            "id": "29",
            "url": "https:\/\/fff.works\/blog\/all\/brief-tasks-preparation-instruction\/",
            "title": "Краткая инструкция для дизайнеров по передаче задач в разработку",
            "content_html": "<div class=\"e2-text-picture\">\n<img src=\"https:\/\/fff.works\/blog\/pictures\/designer@2x.png\" width=\"720\" height=\"405\" alt=\"\" \/>\n<\/div>\n<p>Вы — дизайнер. Вы нарисовали макет и хотите претворить его в жизнь. Инструкция поможет вам получить хороший результат.<\/p>\n<p><b>1. Осознайте свою беспомощность.<\/b> Сами вы макет не внедрите. Даже если умеете программировать, любой серьёзный продукт в десять раз сложнее, чем вы можете себе представить. Трогать продакшен-код вашими дизайнерскими руками вам никто не даст, поэтому работа с разработчиком ваш единственный способ реализовать задуманное. Примите это.<\/p>\n<p><b>2. Подготовьте качественную задачу.<\/b> Работа разработчика внедрить то, что вы придумали, а не придумывать решение за вас. Продумайте, прорисуйте и хорошо опишите всё: основной сценарий, краевые условия, исключительные ситуации. Продумайте структуру данных, алгоритмы, триггеры.<\/p>\n<p>При подготовке задачи вы не сможете обойтись без помощи разработчика. Заранее обсудите с ним задачу, расспросите о подводных камнях, вариантах реализации, наиболее сложных моментах в придуманном дизайне.<\/p>\n<p>Не бойтесь переборщить с детализацией задачи. Даже если вы полностью запрограммируете прототип своего макета, разработчику останется ещё уйма работы по его внедрению в настоящий продукт.<\/p>\n<p><b>3. Помогите сказать «нет».<\/b> Если под вашим давлением разработчик возьмёт некачественную задачу, а потом не сможет её решить, пострадаете в первую очередь вы. Лучше узнать о проблеме на берегу, чем в открытом море. Помогите разработчику отказаться от негодной задачи:<\/p>\n<ul>\n<li>Чего не хватает в макете?<\/li>\n<li>Какие могут быть проблемы?<\/li>\n<li>Что я не учёл?<\/li>\n<\/ul>\n<p><b>3. Убедитесь, что назначен дедлайн и забиты «гвозди».<\/b> Задача без дедлайна не может быть решена по определению. Одного дедлайна недостаточно, нужны промежуточные чекпоинты — «гвозди».<\/p>\n<p>Если разработчик не знает принцип «сделать», мягко подтолкните его вопросами:<\/p>\n<ul>\n<li>Когда сделаешь?<\/li>\n<li>Что будет к этому сроку?<\/li>\n<li>Когда посмотрим промежуточные результаты?<\/li>\n<li>Сколько времени нужно на тестирование? Когда его нужно начать, чтобы уложиться в срок?<\/li>\n<\/ul>\n<p>Если разработчик понимает принцип «сделать», попросите назначить дедлайн и забить гвозди напрямую: «Пожалуйста, назови дедлайн и забей гвозди».<\/p>\n<p><b>5. Крутите педали.<\/b> Не ведите себя как плохой клиент, который только воротит носом и насыпает правки. Проактивно помогайте разработчику решить задачу — прорисовывайте дополнительные сценарии, придумывайте поведение, предлагайте решения, изобретайте упрощения. Ваша работа помочь разработчику сделать.<\/p>\n<p><b>6. Не лезьте не в своё дело.<\/b> Не сомневайтесь в профессионализме разработчика. Не лезьте в код. Если у разработчика не получится реализовать, задавайте наводящие вопросы, чтобы разработчик мог сохранить лицо:<\/p>\n<ul>\n<li>А как вы пробовали решить проблему?<\/li>\n<li>А почему вот это не сработает?<\/li>\n<li>А я вот слышал о таком способе…<\/li>\n<\/ul>\n<p><b>7. Примите результат.<\/b> Выделите себе отдельное время, чтобы проверить работу. Не рассчитывайте, что разработчик сделает это качественно. Он видит только часть системы и не может быть конечным контролёром.<\/p>\n<p><b>Итого<\/b><br \/>\nНе будьте мудаком. Работайте. Помогите разработчику сделать. Растите разработчиков, чтобы сделать коммуникацию проще, а результаты лучше.<\/p>\n<p>P. S. Расскажите разработчику <a href=\"http:\/\/fff.works\/blog\/all\/brief-do-instruction-for-developers\/\">об инструкции по сделыванию<\/a>, это упростит коммуникацию.<\/p>\n",
            "date_published": "2017-12-11T09:57:06+04:00",
            "date_modified": "2017-12-11T09:57:01+04:00",
            "image": "https:\/\/fff.works\/blog\/pictures\/designer@2x.png",
            "_date_published_rfc2822": "Mon, 11 Dec 2017 09:57:06 +0400",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "29",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/fff.works\/blog\/pictures\/designer@2x.png"
                ]
            }
        },
        {
            "id": "27",
            "url": "https:\/\/fff.works\/blog\/all\/brief-do-instruction-for-developers\/",
            "title": "Краткая инструкция по сделыванию для разработчиков",
            "content_html": "<div class=\"e2-text-picture\">\n<img src=\"https:\/\/fff.works\/blog\/pictures\/eyes@2x.jpg\" width=\"776\" height=\"582\" alt=\"\" \/>\n<\/div>\n<p>Вы разработчик. К вам пришёл дизайнер и просит реализовать дизайн. Инструкция поможет вам выполнить свою работу хорошо. Выполните пункты последовательно:<\/p>\n<p><b>1. Осознайте ответственность.<\/b> Как только вы возьмёте задачу, между вами и дизайнером возникнут отношения исполнитель ↔ клиент. Вы — исполнитель. За взятую задачу будете отвечать вы и только вы, поэтому, если не сможете реализовать, если не успеете, если в дизайне чего-то не хватит — проблемы ваши. Хороший дизайнер поможет решить проблему, но целиком полагаться на помощь дизайнера безответственно.<\/p>\n<p>Представьте, что задача — это пластилин. Как только вы берёте задачу, вы берёте «пластилин» в руки. Вернуть «пластилин» дизайнеру можно только двумя способами: 1) сделать и отдать слепленную фигурку — результат, 2) провалить задачу и отдать измятый пластилин — недоделанную работу и набор причин, почему вы провалились. Пока «пластилин» у вас в руках, за него отвечаете вы.<\/p>\n<p><b>2. Поймите задачу.<\/b> За задачу отвечаете вы, поэтому на вашей совести задать все вопросы, запросить все материалы, оговорить все нюансы по задаче. Если чего-то не хватает или вы не верите, что справитесь — не берите задачу. Если взяли — сделайте, не смотря ни на что.<\/p>\n<p>Чтобы понять задачу задавайте вопросы:<\/p>\n<ul>\n<li>В чём польза задачи?<\/li>\n<\/ul>\n<ul>\n<li>Кто этим будет пользоваться?<\/li>\n<\/ul>\n<ul>\n<li>Почему её важно сделать именно сейчас?<\/li>\n<\/ul>\n<ul>\n<li>Как эта задача связана с другими частями системы и с другими задачами? Что ещё придётся изменить в связи с этим в других местах?<\/li>\n<\/ul>\n<ul>\n<li>К какому сроку вы бы хотели получить решение?<\/li>\n<\/ul>\n<ul>\n<li>Почему это критично реализовать к указанному сроку?<\/li>\n<\/ul>\n<p>Если задача сложная, сами напишите, как собираетесь её решить и утвердите получившуюся спецификацию у дизайнера.<\/p>\n<p>Не бойтесь сказать «нет». Вы всем поможете, если не возьмёте негодную задачу, а если возьмёте и не справитесь — всех подведёте.<\/p>\n<p><b>3. Назовите дедлайн.<\/b> Дизайнеру нужен результат. Результат не бывает без срока. Оцените задачу и назовите дату, когда задача будет решена. В срок заложите всё, что необходимо для решения задачи: время на разработку, согласование с дизайнером, возможную переделку, тестирование, полировку и публикацию. В обещанный день и час решение должно быть в продукте, а не на вашем тестовом стенде, потому что результат — это запуск.<\/p>\n<p><b>4. Забейте гвозди.<\/b> Решение задачи зависит от дизайнера. Только он может сказать сделано или нет, поэтому до запуска вам необходимо показать ему промежуточные результаты несколько раз. Это нужно <i>вам<\/i>, чтобы сделать <i>вашу<\/i> работу. Поэтому договоритесь с дизайнером о конкретных датах — гвоздях, когда вы покажете промежуточные результаты. Если задача на неделю, у вас должно быть два — три гвоздя.<\/p>\n<p><b>5. Оставьте запас времени.<\/b> Не планируйте впритык. Что-то обязательно пойдёт не так. Вы столкнётесь с неуловимым багом, дизайнер десять раз попросит подвинуть кнопочку, проект не соберётся, комп заглючит, свет отрубят. Заложите 20% запаса в срок, он вас спасёт.<\/p>\n<p><b>6. Сделайте.<\/b> Добейтесь результата в срок. Если не будете укладываться — придумайте, как упростить и предложите упрощение дизайнеру. Знать, что не успеваете и молчать — отстой. Упростить и не согласовать с дизайнером — отстой. Не успеть и молча продолжать делать — отстой. Ждать, что упрощение придумает дизайнер — отстой.<\/p>\n<p><b>7. Сдайте.<\/b> Утвердите работу у дизайнера. Он ваш клиент. Если он не сказал «ОК», вы не сделали, даже если вы всё запрограммировали и всё работает. Пока не сдали «пластилин» в ваших руках.<\/p>\n<p><b>Итого<\/b><br \/>\nНа входе у вас << задача, макеты, пожелания дизайнера по сроку.<\/p>\n<p>На выходе в день старта >> ваше понимание задачи (спецификация), дедлайн, набор контрольных точек — гвоздей.<\/p>\n<p>В день дедлайна >> «ОК» от дизайнера и опубликованное в продукте решение.<\/p>\n<p>P. S. Если всё-таки сорвали срок, признайте это как можно быстрее. Если дизайнер согласен работать с вами дальше, вернитесь к пункту 1. У вас должно возникнуть новое понимание задачи, новый дедлайн и новый набор контрольных точек.<\/p>\n<p>P. P. S. И без детского сада, пожалуйста. Вам не нужен менеджер, чтобы следить за своими задачами.<\/p>\n",
            "date_published": "2017-12-03T21:28:09+04:00",
            "date_modified": "2017-12-06T10:52:45+04:00",
            "image": "https:\/\/fff.works\/blog\/pictures\/eyes@2x.jpg",
            "_date_published_rfc2822": "Sun, 03 Dec 2017 21:28:09 +0400",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "27",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/fff.works\/blog\/pictures\/eyes@2x.jpg"
                ]
            }
        }
    ],
    "_e2_version": 3860,
    "_e2_ua_string": "E2 (v3860; Aegea)"
}