Каким образом получаешь требования к заданиям?

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

Первое — это, конечно, документация. Ты её открываешь, а там либо пусто, либо написано такое, что хоть святых выноси. "Техзадание"? Да это обычно три строчки на салфетке, нарисованные кривой рукой после пятой рюмки. "User stories"? "Как пользователь, я хочу, чтобы всё работало хорошо". Ну спасибо, ёпта, просветил! Сидишь, гадаешь на кофейной гуще, что же имел в виду этот гениальный продукт-оунер.

Второй пункт — обсуждения. О, это моё любимое! Собирается митинг, все такие важные, умные слова говорят: "фреймворк", "интеграция", "скейлится". Ты сидишь, киваешь, а в голове один вопрос: "Мужики, а нахуя?" Начинаешь задавать уточняющие вопросы, а тебе в ответ: "Ну это же очевидно!" или "Сделайте как вон у того, только чтобы по-другому". Ебать, да я уже сам от себя охуеваю.

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

Вот, смотри, как обычно пытаются формализовать эту хуйню, чтобы хоть как-то спасти ситуацию:

// Пример: Уточнение формата данных для API
public class ApiRequirement
{
    [Required] // Обязательно, а то опять забудем, мудаки!
    public string Endpoint { get; set; }
    [Range(1, 100)] // Не больше ста попыток, а то сервер сдохнет, ебанаты!
    public int MaxRetries { get; set; }
}

И главное, что нужно помнить, чтобы не сойти с ума, три простых правила:

• Фиксируй всё письменно. Обсуждали что-то устно? Завтра этот чувак придёт и будет божиться, что он такого не говорил. Письмо, чат, хоть на стене маркером — но пусть будет доказательство, блядь.
• Задавай уточняющие вопросы, пока не станет понятно даже твоей бабушке. Не стесняйся выглядеть идиотом. Лучше выглядеть идиотом на этапе обсуждения, чем потом, когда всё уже наебнулось и дедлайн горят.
• Сначала проверь, а не ебёшь ли ты лысого? То есть, реализуемость. Прежде чем обещать золотые горы, прикинь, а потянешь ли ты это технически, или это очередная поездка в пизду на велосипеде.

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