L>С мыслью согласен но пример не удачный. раньше и полноценную ОС можно было написать в одиночку.
Хм-м-м... Что такое полноценная ОС? ОС класса CP/M и сейчас можно написать в одиночку и даже быстрее, чем раньше.

Здравствуйте, maxus78, Вы писали:

M>Это термин из области управления персоналом. Вертикально — это от солдата до генерала. А горизонтально — это солдат со знаниями генерала.

А где Вы найдете лоха, который имея знания согласится работать на вторых ролях?

VM>А где Вы найдете лоха, который имея знания согласится работать на вторых ролях?
Не забывайте, что знания, еще не значит умения.

Здравствуйте, Nikolay_Ch, Вы писали:

VM>>А где Вы найдете лоха, который имея знания согласится работать на вторых ролях?
N_C>Не забывайте, что знания, еще не значит умения.

Вертикальный рост — это рост обычного специалиста до руководителя, горизонтальный — до эксперта.

Здравствуйте, maxus78, Вы писали:
> Но тенденция настораживает — люди хотят все меньше делать за все большие блага

Хех, а Вы что же, как влаелец бизнеса (бизнесмен), желаете делать очень много и получать мало прибыли???
Я бы к Вам не пошел работать, так как с таким подходом прибылей не увидишь.

Здравствуйте, BulatZiganshin, Вы писали:

M>>Естественно, я не буду прогибать мир под себя. И, возможно, даже воспользуюсь некоторыми из советов, данными мне в этой конференции. Но тенденция настораживает — люди хотят все меньше делать за все большие блага

BZ>интересное наблюдение от человека, который не разбираясь в разработке программ, хочет ею руководить
ага, очень похоже на то, что создатели этой фирмы не только не имели вообще опыта программирования, не говоря о том, что бы хотя бы пару-тройку лет поработать хотя бы на позиции тимлидера. Был бы опыт реального руководства людьми в непосредственном контакте, думаю, подобный топик не появился бы вообще. Налицо, полное непонимание процесса разработки, как его формальных сторон, так и неформальных(которые тоже оказывают огромнейшее влияние).
Совет автору топика: пойти для начала тимлидом, затем ПМ-ом в какую-нить контору. Сдать 3-4 проекта успешно. После этого, опять вернуться в эту фирму и тогда, думаю, полученный опыт очень поможет без проблем набрать нужных людей, и удержать
П.С. а вообще. важен любой опыт успешный опыт управления, может даже в других сферах.

Здравствуйте, maxus78, Вы писали:
M>Столкнулся с ситуацией — приходит человек на работу, работает какое-то время, потом уходит, мотивируя тем, что работа ведется не по классическим технологиям, техзадания неконкретные, код не по Макконелу, архитектура не по паттернам проектирования и вообще, мол, хочу в крупную компанию.
Охотно верю что люди бегут. Без формализации техзадания (я говорю не об архитектуре, а о самой аналитике) большая часть кода просто выбрасывается либо круто перерабатывается. Программистам всегда обидно когда приходится выбрасывать плоды своего труда, или их труд оказывается не подходящим для решаемой задачи.

M>Да, действительно, мы не используем в работе никакой из современный методологий разработки ПО; да, формализация задач слабая; да, работа не вполне регламентирована и упорядочена. Но надо же четко понимать, что москва не сразу строилась и все такое. Любая компания начинала с комнатки в нии и два разработчика за пыльным столом.
Любая компания занимающаяся творчеством имеет ту или иную степень бардака. Вопрос насколько бардак организован, формализован и поддерживается всеми членами команды.


M>Зато у нас высокая степень самостоятельной организации труда и широкий простор для творчества. В том плане, что никто не заставляет тебя писать код по предварительно нарисованным UML-диаграммам, приветствуется самообразование, никто не бегает и не орет, что сорки летят (под задачу выделяются сроки заведомо большие, чтобы человек имел возможность попробовать разные варианты решения задачи) ит.д. ит.п.

M>А люди бегут.
Уверен что так. И это хорошо(по крайней мере, для программистов). Для программиста видеть свой результат работы не в меньшей степени важно чем зарплата. Они вполне ощущают ответсвенность за то что они создают. А у вас еще, наверняка, фазы тестирования как таковой нет. В результате программист видит то, что его код не выходит из рефакторинга, большую часть времени он не создает что-то новое, а исправляет ошибки пришедшие от пользователя в режиме dead-line. Они правильно поступили. Как настоящие и ответсвенные пацаны.

M>Что делать, господа?

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

Не ложить ответвенность на одного программиста. Ввести code-review, и как можно больше решений принимать коллегиально. Например, при какой-то задаче, коллегиально обсудить и разбить ее на более мелкие но понятные задачи. После каждого решения подзадачи — другой программист должен выкатить список замечаний. Если пришла ошибка, то ее может решить каждый из програмистов. Тут более важно насколько критична ошибка, а не кто ее решает. Как результат, программист чуствует не то что он, или некто другой напортачил, а то, что он помог команде. Это кстати очень поможет самоорганизации процесса программирования(хотя без профи, первоначально это будет метод проб и ошибок). Каким образом дальше улучшить процесс, они сами найдут способ. Главное им не мешать.

Иметь тестера. Баги в большей степени не должны уходить за пределы команды. Если бага нашлась на тестировании, она менее чуствительна. При этом нужно всегда обращать внимание на взаимоотношения тестеров и программеров. Тут могут быть проблемы которые нужно оперативно решать. (кстати, бывает что в роли тестера выступает PM. Как результат, любая мелочь для программиста будет переводиться как "ни фига у вас ничего не работает". К роли тестера нужно очень аккуратно относиться. )

Здравствуйте, maxus78, Вы писали:

M>Да, действительно, мы не используем в работе никакой из современный методологий разработки ПО; да, формализация задач слабая; да, работа не вполне регламентирована и упорядочена. ...

M>Зато у нас высокая степень самостоятельной организации труда и широкий простор для творчества. В том плане, что никто не заставляет тебя писать код по предварительно нарисованным UML-диаграммам, приветствуется самообразование, никто не бегает и не орет, что сорки летят (под задачу выделяются сроки заведомо большие, чтобы человек имел возможность попробовать разные варианты решения задачи) ит.д. ит.п.


Часто в компаниях (я не говорю что у вас) берут человека на должность "программиста/разработчика" и очень хотят что бы он сам принимал решения и ставил себе задачи (как менеджер); проектировал архитектура системы (как архитектор); документировал задание, и архитектуру; реализовывал и программировал (как обычный кодер на должность, которого его и наняли); затем этот человек должен как руководитель тестирования составить планы тестов и описать их, затем как рядовой тестер должен протестировать и задокументировать и так далее. Это еще не упоминается что скорее всего ему еще нужно будет заниматься рядовыми IT-проблемами: настройка ПО (bugzilla'у там установить, или еще чего), еще скорее всего на него повесят задачи по поддержки клиентов (или там сотрудников компании) — которые будут звонить ему как службе поддержки).
В итоге от человека хотят чтобы он совмещал в себе весь этот ворох должностей, был компетентен в каждой и ПРИ ЭТОМ получал зарплату обычно кодера! Плюс еще на собеседовании ему скорее всего давались именно кодеровские задачки? А уж про то что он должен отдать всю свою душу какой-то компании я вообще молчу!

Здравствуйте, maxus78, Вы писали:

M>Зато у нас высокая степень самостоятельной организации труда и широкий простор для творчества. В том плане, что никто не заставляет тебя писать код по предварительно нарисованным UML-диаграммам, приветствуется самообразование, никто не бегает и не орет, что сорки летят (под задачу выделяются сроки заведомо большие, чтобы человек имел возможность попробовать разные варианты решения задачи) ит.д. ит.п.


Такое бывает?!
Сразу захотелось у вас работать.

Бежать могут потому, что зарплата низкая, а сказать прямо стесняются.

Здравствуйте, maxus78, Вы писали:

M>Что делать, господа? Как найти и удержать разработчика, чтобы он приходил на работу не отработать номер и получить зарплату, а как-то был заинтересован в результатах труда, в развитии не только себя любимого (ну все, господа, я всему у вас научился, бывайте), но и компании, в которой он работает?

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

При приеме на работу надо не только оценивать профессиональные качества, но и выяснять, впишется ли человек именно в вашу команду, с вашими методами работы. Имеет смысл и человеку побольше про себя рассказать, чтобы он сам задумался, туда ли он идет. Многие люди стесняются задавать на собеседовании "неудобные" с их точки зрения вопросы (боятся не понравиться работодателю) — я бы посоветовал что-то рассказать про себя своими словами, и предложить человеку не стесняться спрашивать.

Здравствуйте, kwas, Вы писали:

M>>А ведь мысль!

K>Дык! Чем кассир не программист кассового аппарата?

Тем, что у кассового аппарата отсутствует Тьюринговская полнота. В отличии от.

Здравствуйте, Pzz, Вы писали:

Такое ощущение, что в ваше конторе соискателей как грязи В сфере 5й год кризис рынка труда, а вы тут — этот будет счастлив в нашей команде, а вот этот не будет. Какой-то слабореалистичный подход.

Здравствуйте, SergeyGotsulyak, Вы писали:

CC>>Кроме оплаты есть еще и климат в коллективе, и необдуманные действия руководства...
SG>Подобное как раз и случается в конторах, которые платить не хотят или не могут. Если оплата труда поставлена четко, нездоровый климат и необдуманные действия не прививаются на здоровом дереве.
К сожалению есть пример бестолкового руководства и не очень здорового климата (за счет действий руководителей) при стабильной оплате, хотя и ниже среднерыночной.

Здравствуйте, Аноним, Вы писали:

А>Такое ощущение, что в ваше конторе соискателей как грязи В сфере 5й год кризис рынка труда, а вы тут — этот будет счастлив в нашей команде, а вот этот не будет. Какой-то слабореалистичный подход.

Дефицит подсолнечного масла никоим образом не компенсируется изобилием масла моторного.

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

Разумеется, критерии подходящести должны быть реалистичными. Т.е., например если Вы выбираете программистов по принципу "штоб блондин, широкоплечий, ростом 2 метра, с дипломом Мехмата МГУ, готовым знанием всего на свете и все задачи на собеседовании решил", то никого, конечно, не найдете. Если принцип сводится к тому, чтобы вписался в команду, обладал определенной профессиональной грамотностью, делал возложенную на него/на нее работу, чувствовал себя достаточно комфортно и стоил столько, сколько Вы можете себе позволить, то таких людей найти вполне реально.

P.S. При последней нашей попытке набрать 1 человека, 5 соискателей дошли до собеседования. 3-х из них можно было бы брать. Пришлось выбрать 1-го, т.к. больше пока бюджет не позволяет.

M>Парадокс, но очень многие хотят работать как маляры что-ли. То есть начальник показал стену, дал пропорцию смешивания краски, дал кисти и валики, объяснил как наносить краску, какими движениями, как краску разбавлять, как штукатурить ит.д. ит.п. И все. После этого можно начинать работу. А если затык — должен быть человек, который этот затык разрулит.

Это слабаки и джуниоры. Серьезный спец так себя вести не будет. Ему это даже чуть унизительно будет.

M>Столкнулся с ситуацией — приходит человек на работу, работает какое-то время, потом уходит, мотивируя тем, что работа ведется не по классическим технологиям, техзадания неконкретные, код не по Макконелу, архитектура не по паттернам проектирования и вообще, мол, хочу в крупную компанию.

Что-то мне подсказывает, что причина не в этом. Что у вас, скорее всего, не просто "не по Макконелу", а несусветный бардак, от которого часть шишек сыпется на данного сотрудника.

Например — нет управления требованиями ни в каком виде. Это намного хуже, чем "не по паттернам" (которые на самом деле нафиг не нужны ) — и действительно может взбесить.

M>Who the fuck is "кодер"? В смысле в теории такое есть, а вот на практике? И чем можно загрузить "кодера"? В смысле что он может делать, а что — нет. И чем отличается от программиста с точки зрения зарплаты?

Кодер — это ваш "маляр" и есть.

CC>К сожалению есть пример бестолкового руководства и не очень здорового климата (за счет действий руководителей) при стабильной оплате, хотя и ниже среднерыночной.

Унизительная тирания нередко сочетается с оплатой выше рынка.

DM>Делаешь team building на основе Agile-методологий. Поможет не поможет -- но весело будет.

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

Здравствуйте, Maxim S. Shatskih, Вы писали:

DM>>Делаешь team building на основе Agile-методологий. Поможет не поможет -- но весело будет.
MSS>Напоминает анекдот про панков, которых попросили зарезать свинью.
А можно анекдот?