Зачем бэкендеру веб-разработки нужно указывать как проектировать систему?
Пошерстив хэдхантер, я обнаружил что вакансия системного аналитика очень востребованная и высокооплачиваемая профессия, предложений на рынке вагон и телега, некоторым даже предлагают от 400К на руки. А что требуют в вакансиях? А там пишут про опыт проектирования микросервиса, опыт проектирования интеграции с брокером, доработки таблиц бд, проектирование апи, бла-бла-бла... Зачем все это нужно в техзадании для разработчика?
Бэкендер, что, не разработает микросервис исходя из просто человеческого описания функционала? Не разберется как отправлять/получать сообщения в/из очередь брокера, чтобы получилась работающая фича? Не сообразит какой лучше сделать эндпоинт и что передавать в квери параметрах/теле запроса? Не сообразит как доработать таблицы базы данных? Не разберется в документации апи внешнего сервиса для интеграции?
Бэкендеры, зачем вам это все нужно описывать в тз?
Если ты смотрел вакансии с ЗП 400к, то там не берут с улицы, берут прежде всего с опытом. У тебя спросят с какими задачами сталкивался, про паттерны, какие проблемы они решают, как правильно спроектировать БД по такому ТЗ и тому подобное.
Нужно доставить 50 тонн продукции в точки продажи.
Бекендер по этому описанию разберется как это сделать?
Может быть там нюансы, что доставлять нужно в маленькие магазинчики в городе с узкими улицами, где фуры не проедут?
Может быть доставлять нужно в супермаркеты крупными партиями?
Может быть доставлять нужно в пределах области по нормальным трассам, с возможностью пересадки на более мелкий транспорт уже перед городом?
А зачем угадывать? Можно просто описать happy path пользоватильского сценария, и сторонние path. Донести человеческим языком что должно отображать на экране у пользователя в том или ином случае.
А тонкости техничсекой реализации отдать на откуп разработчику. Он же разрабатывает, так пусть и продумает как лучше спроектировать на техническом уровне.
Потому что бекендер не всегда знает где его компонент будет запускаться, в каких количествах, как реализованы другие компоненты чтобы писать "под них".
В программировании всегда есть много вариантов как что-то сделать.
Saboteur, да благодарю, Aetae Aetae тоже тоже мне это написал. В целом если взять весь зоопарк внутрянку которая есть, то становится понятно почему 300-400-500К могут предлагать, я всегда думал, что важно happy path описать, и сторонние path. На этом все.
А зачем угадывать? Можно просто описать happy path пользоватильского сценария, и сторонние path. Донести человеческим языком что должно отображать на экране у пользователя в том или ином случае.
Мне казалось, что это - часть работы системного аналитика. К тому же, разработчик может оказаться тупым кодером ( зато и з/п у него ниже, чем у полноценного разработчика)
Системный аналитик должен понимать систему. Поэтому, если в системе микросервисная архитектура, управляемая событиями, распространяемыми через очереди, то аналитик должен знать, как всё это работает. К тому же аналитики не только ТЗ пишут.
Знать как работает - разве не задача разработчика? Он же и пишет код. Значит он и знает лучше всех. Сомневаюсь что аналитикам дают доступ к кодовой базе. Зачем в тз описывать все эти сложности? Ведь можно описать happy path пользоватильского сценария, и сторонние path. Донести человеческим языком что должно отображать на экране у пользователя в том или ином случае.
А тонкости техничсекой реализации отдать на откуп разработчику. Он же разрабатывает, так пусть и продумает как лучше спроектировать на техническом уровне.
Сергей Горностаев, вот в том то и дело. Не понимаю для чего нужно знать систему, когда можно описать happy path пользоватильского сценария, и сторонние path. Донести человеческим языком что должно отображать на экране у пользователя в том или ином случае. Вот это и есть тз для прогера. И он уже сам начинает подключать брокеры, создавать микросервисы и прочее.
NickFortune, тогда со стороны бэка должен быть бэк-чувак с точно такими же требованиями, должность у него называться будет "архитектор", или как-то так.:)
Простой разработчик тебе так твой happy path нахреновертит, что сам не рад будешь.
NickFortune, как я уже говорил, аналитики не только ТЗ пишут. Например у меня в проекте они появились недавно и она занимаются документированием системы. Причём отвлекать разработчиков от написания кода им нельзя, сами должны во всём разбираться. Почти всегда, когда в проекте появляется аналитики - это попытка руководства проекта разгрузить других специалистов (менеджеров, разработчиков, архитекторов и т.д.) от лишней работы - общения с клиентами и интеграционными партнёрами, формализации задач, написания документации и т.п.
1) Если у вас они в проекте появились недавно, то кто писал тз на функционал в проекте ДО них?
2) Про документирование - спасибо, это ценно для понимания сути профессии. Но тогда закономерный вопрос: на сколько "низкоуровневой" должна быть документация? Должны ли в ней перечисляться все технические сложности которые я указал в вопросе, или достаточно happy path?
3) Если аналитику запрещено отвлекать разработчика от написания кода, то как понять, что система была задокументирована верно и аналитик правильно разобрался? Без разработчика никак. Только разработчик по коду проверит и завизирует: да, система работает именно так, или нет, у нас иная реализация.
Если у вас они в проекте появились недавно, то кто писал тз на функционал в проекте ДО них?
Либо менеджер проекта писал таски с ужасной постановкой, либо разработчикам приходилось самим ходить на бизнесовые созвоны с заказчиком.
Но тогда закономерный вопрос: на сколько "низкоуровневой" должна быть документация? Должны ли в ней перечисляться все технические сложности которые я указал в вопросе, или достаточно happy path?
Настолько, чтобы если вся команда разработки разом уволится, менеджмент смог понять кого нужно нанять, а нанятые смогли быстро погрузиться. То есть чем детальнее, тем лучше.
Если аналитику запрещено отвлекать разработчика от написания кода, то как понять, что система была задокументирована верно и аналитик правильно разобрался?
По полезности получившейся документации. Если пришёл заказчик с хотелкой и сами аналитики вместе с менеджерами смогли по документации понять фронт необходимых работ, значит хорошая документация. Если пришёл заказчик с проблемой и без привлечения разработчиков удалось примерно понять из-за чего она, значит хорошая документация. Если наняли нового разработчика и он смог начать работать не дёргая тимлида, значит хорошая документация. И т.д. и т.п.
Сергей Горностаев, стало грустно что в банках так писали тз( ломается стериотип что банки это надежность, качество, современные технологии бла бла бла.
У меня еще родился один вопрос. Если вы считаете что он конфиденциального уровня то я пойму, тогда, конечно не отвечайте. Но мне правда интересно: и сколько же денег банк предлагает в месяц системному аналитику у вас?
Буквально несколько дней назад вы писали что у вас двухгодовалых не бог весть каких разработчиков сманивают за 300тысяч. А я в вакансиях на аналитика вижу в основном до тех же 300. Свыше 300 - только очень опытным. От 400 (это я писал в вопросе) это видимо какой-то заоблачный уровень... Еще я даже как-то видел от 500 в месяц. Мне даже страшно подумать за что аналитик модет получать такие деньги. В то же время документирование системы не выглядит высокооплачиваемым занятием, и если поможете узнать сколько банк предлагает системным аналитикам, буду благодарен.
Бэкендер, что, не разработает микросервис исходя из просто человеческого описания функционала? Не разберется как отправлять/получать сообщения в/из очередь брокера, чтобы получилась работающая фича? Не сообразит какой лучше сделать эндпоинт и что передавать в квери парамтерах/теле запроса? Не сообразит как доработать таблицы базыданных? Не разберется в документации апи внешнего сервиса для интеграции?
Теперь понятно из-за кого спрос на гадалок возрастает
Причем тут гадалки....Почему нельзя просто описать happy path пользоватильского сценария, и сторонние path. Донести человеческим языком что должно отображать на экране у пользователя в том или ином случае.
А тонкости техничсекой реализации отдать на откуп разработчику. Он же разрабатывает, так пусть и продумает как лучше спроектировать на техническом уровне.
Даже в небоьлших проектах где заказчик далеко от разработчика на выходе получается , не то про внешнему виду не то, по функционалу совсем не то. Собственно всякие гибкие разработки в виде скрама и канбана например как раз решают эту проблему.
