это уже следующий шаг в суеверии- считать что удача и неудача выдается порционно и планировать, куда что потратить. странно что вас не заминусовали, походу сегодняшняя удача у вас ушла на это. :)
ИМХО контроль имеет смысл только в вопросах безопасности.
сколько кто работает… да ведь намного проще, дешевле и выгоднее контролировать результат. И формировать штат исходя из результатов, а не колва часов надавливания штанами кресла в офисе, щелчков мышки или других косвенных параметров
А, тогда понятен ваш комментарий :)
Да, я имел ввиду «менеджер сказал запилить фичу в нереальные сроки, сделаю что-то работающее, но не все. А как он объяснит начальству что успели сделать не все — не моя проблема».
Еще дополню свою мысль :)
М: смог вытащить этот проект за такой малый срок. Так что меня повысили
М2: Какие мы молодцы… я вместе с Гуру перевожусь в другой отдел
«и решают сделать новую систему» — под руководством М3, видимо.
Т.е. М, М2, М3 и Гуру- в шоколаде (4 чел).
А разработчик: в какашках (1 чел)
И это все по результатам работы над одним и тем же проектом! Ну и кто из этих 5ти людей некомпетентный дуралей? :)
«Так и сказали, что я мастер управлением персоналом, что смог вытащить этот проект за такой малый срок. Так что меня повысили». Вот на этом моменте разрабу надо было ультимативно получать повышение, либо уходить с повышением зп. А когда дошло бы до «решают сделать новую систему» — получить еще 2 разраба и еще одно повышение.
Это какой-то экстремальный случай- с посадкой. 95% софта все-так не несет серьезных последствий в случае уязвимостей/багов/недоработок. И отделен от программиста несколькими слоями- тестирование, приемка, проверка на уязвимости, поддержка на лайве.
Попробую еще другими словами дополнить свою мысль.
Разработчик — это не тот, кто отвечает за проект. Описанный в статье разработчик переживает насчет вещей, которые вообще не находятся в его компетенции. Он не знает, на каких исходных данных принимались решения выше, может это политические игры руководства и через 2 года этот продукт вообще не будет нужен. А может нужен, но они ошиблись в решениях. Но ошиблись то — они, а не разработчик.
Это как сборщик айфонов в Китае будет переживать — а как же таким телефоном будут пользоваться люди, неудобно ведь и неоправданно дорого! А через год все их повыкидывают и будут покупать новые! А старые станут такими медленными на новой оси. И уволится из-за этого, хотя предлагали нормальную зп.
Тут надо понимать, что вы хотите
а) писать очень «правильный» софт с грамотными: ТЗ, архитектурой, выбранными технологиями, процессами разработки и деплоя, покрытиями тестами и современными стандартами по написанию самого кода.
б) долго работать программистом в крупной компании с повышениями и ростом ЗП.
Действия в статье описаны для человека, который хочет исключительно пункт А.
Можно для себя выбрать Б, а из «а» брать по возможности.
«А потом «это» десяток лет развивать и поддерживать» — ответил ниже.
Из-за вашего кода посадят кого-то в компании заказчика? Ерунда какая-то.
Neikist: «А потом «это» десяток лет развивать и поддерживать, плюс под каждый проект чуть ли не с нуля переписывать» зачастую это может быть и неплохо.
Надо смотреть что это за система, если это управление аппаратом по лазерной коррекции зрения- там я бы так делать не стал.
А если скажем… какой-нить документооборот в крупной компании- именно так как вы описали оно и делается в 90% не-айтишных компаний, например в строительной или нефтедобывающей. Эти все велосипеды на костылях потом надо поддерживать и дописывать- штат сотрудников увеличивается, а это означает повышение, рост зарплат.
Это хороший пример что будет, если понимать все буквально, биться головой в стену и считать работой программиста написание кода, сверяясь с книжкой «Идеальный код» МакКонела.
В компании есть деньги, менеджер, СЕО и випы заинтересованы чтобы проект был принят. Этого достаточно чтобы где-то сделать по-своему, где-то сорвать сроки, где-то скорректировать требования, кого-то мягко проигнорировать, но сделать что-то работающее, что будет принято и будет развиваться дальше и может и будет кривое, но работающее и даже приносящее прибыль компании. Получить соответственно повышение зп и бонус.
Просто надо быть хитрее.
это уже следующий шаг в суеверии- считать что удача и неудача выдается порционно и планировать, куда что потратить. странно что вас не заминусовали, походу сегодняшняя удача у вас ушла на это. :)
ИМХО контроль имеет смысл только в вопросах безопасности.
сколько кто работает… да ведь намного проще, дешевле и выгоднее контролировать результат. И формировать штат исходя из результатов, а не колва часов надавливания штанами кресла в офисе, щелчков мышки или других косвенных параметров
Да, я имел ввиду «менеджер сказал запилить фичу в нереальные сроки, сделаю что-то работающее, но не все. А как он объяснит начальству что успели сделать не все — не моя проблема».
Еще дополню свою мысль :)
М: смог вытащить этот проект за такой малый срок. Так что меня повысили
М2: Какие мы молодцы… я вместе с Гуру перевожусь в другой отдел
«и решают сделать новую систему» — под руководством М3, видимо.
Т.е. М, М2, М3 и Гуру- в шоколаде (4 чел).
А разработчик: в какашках (1 чел)
И это все по результатам работы над одним и тем же проектом! Ну и кто из этих 5ти людей некомпетентный дуралей? :)
«Так и сказали, что я мастер управлением персоналом, что смог вытащить этот проект за такой малый срок. Так что меня повысили». Вот на этом моменте разрабу надо было ультимативно получать повышение, либо уходить с повышением зп. А когда дошло бы до «решают сделать новую систему» — получить еще 2 разраба и еще одно повышение.
Попробую еще другими словами дополнить свою мысль.
Разработчик — это не тот, кто отвечает за проект. Описанный в статье разработчик переживает насчет вещей, которые вообще не находятся в его компетенции. Он не знает, на каких исходных данных принимались решения выше, может это политические игры руководства и через 2 года этот продукт вообще не будет нужен. А может нужен, но они ошиблись в решениях. Но ошиблись то — они, а не разработчик.
Это как сборщик айфонов в Китае будет переживать — а как же таким телефоном будут пользоваться люди, неудобно ведь и неоправданно дорого! А через год все их повыкидывают и будут покупать новые! А старые станут такими медленными на новой оси. И уволится из-за этого, хотя предлагали нормальную зп.
а) писать очень «правильный» софт с грамотными: ТЗ, архитектурой, выбранными технологиями, процессами разработки и деплоя, покрытиями тестами и современными стандартами по написанию самого кода.
б) долго работать программистом в крупной компании с повышениями и ростом ЗП.
Действия в статье описаны для человека, который хочет исключительно пункт А.
Можно для себя выбрать Б, а из «а» брать по возможности.
«А потом «это» десяток лет развивать и поддерживать» — ответил ниже.
Neikist: «А потом «это» десяток лет развивать и поддерживать, плюс под каждый проект чуть ли не с нуля переписывать» зачастую это может быть и неплохо.
Надо смотреть что это за система, если это управление аппаратом по лазерной коррекции зрения- там я бы так делать не стал.
А если скажем… какой-нить документооборот в крупной компании- именно так как вы описали оно и делается в 90% не-айтишных компаний, например в строительной или нефтедобывающей. Эти все велосипеды на костылях потом надо поддерживать и дописывать- штат сотрудников увеличивается, а это означает повышение, рост зарплат.
В компании есть деньги, менеджер, СЕО и випы заинтересованы чтобы проект был принят. Этого достаточно чтобы где-то сделать по-своему, где-то сорвать сроки, где-то скорректировать требования, кого-то мягко проигнорировать, но сделать что-то работающее, что будет принято и будет развиваться дальше и может и будет кривое, но работающее и даже приносящее прибыль компании. Получить соответственно повышение зп и бонус.
Просто надо быть хитрее.
Зачем?