Всем доброго времени суток!

Давно мучаюсь с определением собственной профессии. Дело в том, что я работаю программистом/руководителем проекта и выполняю самые разные задачи.
Это изучение материалов по проекту (ТЗ + протоколы + дополнительные материалы), формирование заданий для других программистов, само программирование. Из проектирования пока получилось только понять и использовать лишь 2 паттерна. Singleton и Observer.
Еще давно изучал UML по Фаулеру и Бучу, но явного применения он у меня не находит, т.к. не совсем понимаю, где его применять и кому это нужно. С компанией в этом плане не повезло, нет технически подкованного руководителя, который бы помог в направлении современных технологий разработки ПО. А у меня нехватка знаний.
Так вот вопрос в следующем... какую литературу читать? (ведь ее так много) Анализ? Требования? Проектирование? UML? Чем из этого всего занимаюсь я? С чего начать?

А какие проблемы вы хотели бы решить?

Самому мне хотелось бы заниматься вопросами проектирования, т.е. быть ближе всего к программированию. Но по роду деятельность приходится постоянно рыть документацию для уточнения требований к проекту, а потом практически минуя проектирование или совмещая его с программированием заниматься реализацией. И даже если я хочу сесть за проектирование, то просто не знаю с чего начать, а если начинаю читать, то все приводит меня к требованиям и спецификации ПО.
Т.е. получается я должен заниматься всем процессом разработки ПО, начиная с анализа и заканчивая реализацией (возможно и тестированием, т.к. тестировщиков у нас нет). Но  когда команда маленькая и неподготовленная к более полному процессу разработки, то руки начинают опускаться, т.к. совместить в себе весь процесс разработки не удается, просто не хватает знаний. И в итоге все сводится к быстрому программированию минуя все этапы разработки.
Мне просто кажется, что в компании, в которой никогда не применялся хоть какой-то из известных процессов разработки ПО, вводить что-то человеку который не имеет опыта в этой области - бесполезно. Ведь это должно вводится сверху, от руководства, а не снизу.
Но как иначе получить опыт в том же проектировании, чтобы куда-то устроиться?

Скоро 28.
По специальности инженер-системотехник. А по делу программист С/C++.
В тех местах где я работал и работаю сейчас применяется единственный способ разработки ПО - выдача ТЗ -> получение результата. А сам процесс никого не интересует и даже никак не отслеживается.

А сам процесс никого не интересует и даже никак не отслеживается.

а зачем?
неужели ТЗ не соответствует потребностям заказчика, а сроки и качество результата - требованиям ТЗ, и разве имеются проблемы с реализацией? :о))
почему нельзя всё это решить элементарной заменой одних исполнителей на других (плохих на хороших)? кому нужно еще и с процессом непонятно каким связываться? это ж только замедляет разработку...

Вы хотите работу сменить или у вас возникают проблемы в процессе разработки ПО?

Вы хотите работу сменить или у вас возникают проблемы в процессе разработки ПО?

Да, я хочу уйти. Но пока я еще не понял куда я хочу уйти, на какую специальность, потому то и обратился к вам за советом. И сейчас меня мучают такие вещи:
1. Я программист.
Часто мне не хватает какого-то проектирования при реализации той или иной программы. Все планирование ведется во время написания кода. Бывает так, что приходится переписывать часть кода, либо применять рефакторинг из-за неудобной реализации или просто пришло в голову что-то более оптимальное. Из-за этого часто появляется мертвый код, т.е. код который уже не используется, но чтобы это определить надо затратить довольно много времени.
2. Мне приходится анализировать ТЗ, разрабатывать общую структуру ПО и выдавать задания другим программистам.
В наших ТЗ часто присутствуют противоречия. Объемы большие и процесс затягивается. Часто получается так, что противоречие найдено позже чем уже есть какой-то вариант реализации. Так же бывает, что часть требований не имеют достаточного описания.

Какое-то время мы применяли в команде XP. Хотя опять же никто не владел этим процессом в полной мере, мы только знакомились с ним. Сейчас от XP осталось только тестирование и то тесты пишутся уже после реализации, а не до нее. Парное программирование не прижилось.

Вопрос заключается в следующем. За что взяться в первую очередь учитывая то что приходится заниматься всем?
Посмотреть RUP или что-то подобное?
Заняться изучением анализа требований?
Углубится в проектирование и изучение шаблонов проектирования?

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

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

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

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

Не исключено, что полученные результаты вас сильно удивят.

По всей видимости вам стоит расти в архитектора.
Посмотрите не словарь/идеологию (Буча) и не каталог типовых решений (паттерны), а методичку по тому, как организовывать работу по созданию ПО с точки зрения архитектора. А именно — Крэга Лармана.

Если я правильно понял, то вам по душе программирование. Ну так в чем проблема? Развивайтесь в данном направлении. Следующим логичным этапом вашей карьеры может быть должность архитектора...Далее находим информацию об этой должности. Просматриваем вакансии, книги, форумы... Выясняем необходимые знания и постепенно набираемся этих самых знаний. И наиболее подходящие стараемся использовать по прямому назначению. По-моему алгоритм достаточно простой.

За вас вам никто цель не поставит...

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

Не знаю, удалось ли мне донести мысль, но я честно попыталась это делать

Что касается ответственности, то с ней у меня все в порядке.
Здесь же я пытаюсь получить совета, с чего лучше начать в моей ситуации.
Интересно мне каждое из этих направлений. Каждое из них требует отдельного внимания.
И я надеюсь получить от профессионалов, которые надеюсь здесь присутствуют, ответ на вопрос: с чего начать?

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

Не исключено, что полученные результаты вас сильно удивят.

Здесь проблемы:

1. Я программист.
Часто мне не хватает какого-то проектирования при реализации той или иной программы. Все планирование ведется во время написания кода. Бывает так, что приходится переписывать часть кода, либо применять рефакторинг из-за неудобной реализации или просто пришло в голову что-то более оптимальное. Из-за этого часто появляется мертвый код, т.е. код который уже не используется, но чтобы это определить надо затратить довольно много времени.
2. Мне приходится анализировать ТЗ, разрабатывать общую структуру ПО и выдавать задания другим программистам.
В наших ТЗ часто присутствуют противоречия. Объемы большие и процесс затягивается. Часто получается так, что противоречие найдено позже чем уже есть какой-то вариант реализации. Так же бывает, что часть требований не имеют достаточного описания.

Какое-то время мы применяли в команде XP. Хотя опять же никто не владел этим процессом в полной мере, мы только знакомились с ним. Сейчас от XP осталось только тестирование и то тесты пишутся уже после реализации, а не до нее. Парное программирование не прижилось.

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

По всей видимости вам стоит расти в архитектора.
Посмотрите не словарь/идеологию (Буча) и не каталог типовых решений (паттерны), а методичку по тому, как организовывать работу по созданию ПО с точки зрения архитектора. А именно — Крэга Лармана.

Спасибо вам большое, за вполне конкретный совет. Уже нашел книгу.

Если я правильно понял, то вам по душе программирование. Ну так в чем проблема? Развивайтесь в данном направлении. Следующим логичным этапом вашей карьеры может быть должность архитектора...Далее находим информацию об этой должности. Просматриваем вакансии, книги, форумы... Выясняем необходимые знания и постепенно набираемся этих самых знаний. И наиболее подходящие стараемся использовать по прямому назначению. По-моему алгоритм достаточно простой.

За вас вам никто цель не поставит...

Спасибо за направление. Программирование действительно по душе, только уже уровень надо поднимать.

А цель ставить за себя я и не дам

Так же я не знаю, имеет ли смысл совмещать в одном человеке функции аналитика, проектировщика, программиста и руководителя проекта?

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

Здесь проблемы:
1. Я программист.
Часто мне не хватает какого-то проектирования при реализации той или иной программы. Все планирование ведется во время написания кода. Бывает так, что приходится переписывать часть кода, либо применять рефакторинг из-за неудобной реализации или просто пришло в голову что-то более оптимальное. Из-за этого часто появляется мертвый код, т.е. код который уже не используется, но чтобы это определить надо затратить довольно много времени.
2. Мне приходится анализировать ТЗ, разрабатывать общую структуру ПО и выдавать задания другим программистам.
В наших ТЗ часто присутствуют противоречия. Объемы большие и процесс затягивается. Часто получается так, что противоречие найдено позже чем уже есть какой-то вариант реализации. Так же бывает, что часть требований не имеют достаточного описания.

Вызывает их мое незнание в этих областях.

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

Здесь же я пытаюсь получить совета, с чего лучше начать в моей ситуации.

Зависит от того, чего вы хотите добиться для вашей организации и для себя лично. Начинать желательно с себя (ибо эффективно совмещать в одном человеке функции аналитика, проектировщика, программиста и руководителя проекта не реально) - больше шансов добиться желаемого. Если же все-таки у вас возникло желание спасти мир вашу компанию, то... Бог вам в помощь!

P.S. А вообще, набор действий для решения проблемы "спасение компании" целиком и полностью зависит от того, как вы определите то, чего вы хотите достичь для себя лично.

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

Поправьте меня если я не прав:
1) Системный аналитик.
Занимается анализом требований. Является связующим звеном между заказчиком и исполнителем.
В чистом виде, я так понимаю, такие существуют только в очень крупных компаниях. В других - чаще это совмещенная должность с кем-то вроде руководителя проекта.
2) Архитектор.
Занимается построением архитектуры системы. На основании требований (собранных аналитиком) формирует структуру комплекса (ПО). Является связующим звеном между аналитиком и разработчиками.
Часто должность архитектора связана с главным/ведущим программистом.
3) Руководитель проекта.
Определяет технологию по которой выполняется проект. Занимается планирование работ. Принимает непосредственное участие в анализе требований и построении архитектуры, больше в качестве руководителя, нежели исполнителя.

Поправьте меня если я не прав:
1) Системный аналитик.
Занимается анализом требований. Является связующим звеном между заказчиком и исполнителем.
В чистом виде, я так понимаю, такие существуют только в очень крупных компаниях. В других - чаще это совмещенная должность с кем-то вроде руководителя проекта.

Вовсе не обязательно. У нас в компании - это вполне выделенная должность. Правда именуется она как бизнес-аналитик, т.е. скорее имеем дело с аналитиком требований. Тем не менее задача аналитика у нас - получение запроса от заказчика, описание требований в общем виде, обсуждение их с проектировщиками, написание постановки на разработку, сопровождение ее в ходе реализации, приемка работу после реализации, написание технологических инструкций по работе с реализованной задачей.

2) Архитектор.
Занимается построением архитектуры системы. На основании требований (собранных аналитиком) формирует структуру комплекса (ПО). Является связующим звеном между аналитиком и разработчиками.
Часто должность архитектора связана с главным/ведущим программистом.

Явного архитектора у нас нет. Есть проектный отдел (в котором правда пока 1 человек и туда также входят на правах консультантов главы отделов прикладной и системной разработки). Собственно система уже есть, возможен рефакторинг архитектуры или перепроектирование каких-то задач

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

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