Комментарии 47
10-й пункт: на самом деле есть лекарство, если чувак говнокодит сейчас и не слушает советов опытных чуваков, он и дальше будет колбасить говнокод и толку с него никакого не будет. Решение только одно — отбор ответственных за свои действия разработчиков в команду, старательных и стремительных. Если этих качеств у разработчика нет, он никогда не будет писать библиотеки и думать о будущем проекта
>>Текучка на проекте – уходят те, кто «в теме», а набирают тех, кто найдут
Лучится очень просто:
подписывается контракт с работником на каждый новый проект по которому он не может разорвать контракт предупредив не за 2 недели а за 2 месяца.
ЗА это неудобство работник получает доп. денег.
А а также всегда должны быть минимум 2 человека, которые разбираются в 1 фиче. Один мастер, а второй хотя бы падаван.
Лучится очень просто:
подписывается контракт с работником на каждый новый проект по которому он не может разорвать контракт предупредив не за 2 недели а за 2 месяца.
ЗА это неудобство работник получает доп. денег.
А а также всегда должны быть минимум 2 человека, которые разбираются в 1 фиче. Один мастер, а второй хотя бы падаван.
Вы уверены, что такой контракт, вернее такой пункт в нём, будет юридически значим?
По договору оказания услуг можно вписать туда неустойку — и вуаля.
Не единым трудовым договором жив рынок работы.
Не единым трудовым договором жив рынок работы.
Человек, привыкший к белой зарплате, соцстраху и т. п., может и не согласиться. Или согласиться, а потом в суд подать с иском о признании отношений трудовыми. Или сообщить «куда следует». В общем ещё дороже может выйти, чем текучка.
Вы хотите сказать, что есть на Руси люди, которые любят судиться с работодателями? И что у них потом все хорошо складывается в жизни?
В теории всё гладко, на практике же…
Может вы даже покажете мне человека, который восстановился на работе через суд и у него все хорошо сложилось на этой работе? (да, это не по теме, но прекрасная иллюстрация для того, как всё у нас с этим плохо. Последний раз интересовался этим года 2 назад, и ничего подобного не нашел).
Мне кажется, Российский национальный колорит во всем этом слишком силен.
В теории всё гладко, на практике же…
Может вы даже покажете мне человека, который восстановился на работе через суд и у него все хорошо сложилось на этой работе? (да, это не по теме, но прекрасная иллюстрация для того, как всё у нас с этим плохо. Последний раз интересовался этим года 2 назад, и ничего подобного не нашел).
Мне кажется, Российский национальный колорит во всем этом слишком силен.
Восстанавливаться у «плохого» работодателя не нужно. А вот съесть ему мозги сразу после увольнения вполне даже можно и нужно. Ибо нефиг.
Я уже на несколько хороших работ из-за таких дурацких договоров не пошел. Проще не идти, чем судиться. Товарищи силились придумать договор о неконкуренции после увольнения, договор о неконкуренции во время работы (в свободное время я кодю опенсорц по той же теме, по какой работаю), адовые договоры о неразглашении, итп. Всех, всех лесом!
Я уже на несколько хороших работ из-за таких дурацких договоров не пошел. Проще не идти, чем судиться. Товарищи силились придумать договор о неконкуренции после увольнения, договор о неконкуренции во время работы (в свободное время я кодю опенсорц по той же теме, по какой работаю), адовые договоры о неразглашении, итп. Всех, всех лесом!
С меня недавно взяли NDA, довольно дурацкую:) при этом не то что не сняв сканы моих документов, но даже туда не заглянув (!) Кстати, читается ли такая NDA действительной, если она скреплена только моей подписью (без документов с надписью «копия верна, число-дата-подпись»)?
Если информация в документе позволяет вас однозначно идентифицировать, то считается. Хотя, конечно, что там записано.
ФИО, серия и номер паспорта. Но мало ли откуда они их взяли? Это так, если что…
Подпись ваша? ФИО, серия и номер паспорта ваши? Вывод — именно вы этот документ подписывали. Вот написали бы левые — в случае конфликта пришлось бы сложнее работодателю. Но если бы доказал свою правоту, то вас вполне могли бы и за мошенничество привлечь. Проверять документы в таких ситуациях не обязанность работодателя, а право.
Если честно, я пожалел, что не написал левые данные :) просто не знал, что они не будут смотреть документы=)
Восстанавливаются по суду не затем, чтобы работать дальше, а чтоб написать по собственному, получить положенное по закону (включая компенсацию за вынужденный прогул) и компенсацию за моральный вред. Плюс трудинспекция может проблем устроить.
НЛО прилетело и опубликовало эту надпись здесь
>> Вы уверены, что такой контракт, вернее такой пункт в нём, будет юридически значим?
Это не граничит с тем, что прописано в законе (в законе говорится, что не менее 2х недель отработать. Отработать != предупредить заранее. Это юридическая тонкость.)
К тому же я писал про контракт, у контракта могут быть другие условия, отличные от бессрочного трудового договора по ТК. В договоре должно быть ясно указано, что за это неудобство человек получает больше денег. Тогда это не нарушает его права.
блин, парни, так не о том же спор. Вы тему затронули того, что человеку плохо работается и он хочет судиться с работодателем. Это совсем иная плоскость.
Если ему плохо работается, то он может после испытательного срока свалить. Испыт. срок — до 3х месяцев может быть. Но если ему работается хорошо, но вдруг предложили больше, то чувак извини. Мы же тебе помогли в трудные времена — взяли на хорошую ЗП, ты получал бонус за то, что обещался предупредить нас за 2 месяца. Получал? Вот и предупреди.
Конечно, если этот пункт — часть соцпакета в 30 т.р. то вряд ли он покажется интересным.
PS 90% трудовых споров выигрываются в пользу работника. Кстати, потому что работодатели сами себе ямы роют часто, уклоняясь от уставных отношений.
Это не граничит с тем, что прописано в законе (в законе говорится, что не менее 2х недель отработать. Отработать != предупредить заранее. Это юридическая тонкость.)
К тому же я писал про контракт, у контракта могут быть другие условия, отличные от бессрочного трудового договора по ТК. В договоре должно быть ясно указано, что за это неудобство человек получает больше денег. Тогда это не нарушает его права.
блин, парни, так не о том же спор. Вы тему затронули того, что человеку плохо работается и он хочет судиться с работодателем. Это совсем иная плоскость.
Если ему плохо работается, то он может после испытательного срока свалить. Испыт. срок — до 3х месяцев может быть. Но если ему работается хорошо, но вдруг предложили больше, то чувак извини. Мы же тебе помогли в трудные времена — взяли на хорошую ЗП, ты получал бонус за то, что обещался предупредить нас за 2 месяца. Получал? Вот и предупреди.
Конечно, если этот пункт — часть соцпакета в 30 т.р. то вряд ли он покажется интересным.
PS 90% трудовых споров выигрываются в пользу работника. Кстати, потому что работодатели сами себе ямы роют часто, уклоняясь от уставных отношений.
Пункты трудового договора, ухудшающие положение работника вроде как являются ничтожными. Максимум это бонус себе сможете забрать назад, если я не предупрежу. Но, наверное, в порядке гражданского спора, а не трудового. То есть сначала выплатите, всё что мне причитается, а потом будете отсуживать бонус.
Условия могут ухудшиться внезапно для работника. Например фирма переехала в офис на другом конце города. Или гиперинфляция, а индексации нет. Или премиальный фонд у фирмы резко опустел.
Вот я и спросил, уверены ли вы, что не попадёте в эти 90%.
Условия могут ухудшиться внезапно для работника. Например фирма переехала в офис на другом конце города. Или гиперинфляция, а индексации нет. Или премиальный фонд у фирмы резко опустел.
Вот я и спросил, уверены ли вы, что не попадёте в эти 90%.
я ещё раз делаю акциент, на том, что контракт и трудовой договор — разные понятия. ТД — это контракт со всеми бонусами от ТК, которые гарантирует гос-во (CMS если хотите).
Контракт как таковой — это срочные договорные отношения (система разработанная с нуля).
В ней описываются все аспекты трудовой деятельности, иногда дублируя ТК.
Да, он не должен быть хуже, чем типичные трудовой договор.
Но в контракте можно прописать, что одним из условий является возможность частого смена места работы, ненормированный график (да, в пределах установленных ТК), наличие или отсутствие авто. И подписавшись под этим работник соглашается.
Также одним из условием разрыва является обязанность сторон предупредить о разрыве не меньше, чем за n месяцев. Блин, ну какое здесь ухудшение условий ТРУДА?
За это работник получает доп плюшки.
Контракт как таковой — это срочные договорные отношения (система разработанная с нуля).
В ней описываются все аспекты трудовой деятельности, иногда дублируя ТК.
Да, он не должен быть хуже, чем типичные трудовой договор.
Но в контракте можно прописать, что одним из условий является возможность частого смена места работы, ненормированный график (да, в пределах установленных ТК), наличие или отсутствие авто. И подписавшись под этим работник соглашается.
Также одним из условием разрыва является обязанность сторон предупредить о разрыве не меньше, чем за n месяцев. Блин, ну какое здесь ухудшение условий ТРУДА?
За это работник получает доп плюшки.
Не боитесь признания такого договора трудовым и получения «вуаля» уже в свою сторону и в куда большем размере?
Коллеги, а «проектный менеджер» — это то же самое что project manager, или что-то другое?
Да, здесь это синонимы
А теперь обратите внимание, насколько все различается в зависимости от типа «проекта». У вас — работа на внешнего заказчика по автоматизации бизнеса. Для кого-то еще — веб проект на средства инвестора. Для другой команды — разроботка игры на собственные деньги. Или тиражируемого коробочного продукта. При этом в каждом случае пересекаться будт меньше половины пунктов вашего списка :).
НЛО прилетело и опубликовало эту надпись здесь
Тоже самое, что и Менеджер проекта, и совсем по-русски Руководитель проекта.
В итоге все упирается в деньги.
По 10 пункту мы так решаем.
1. Сделали ставки на несколько опенсорс платформ: фреймворк и пару специфичных цмс.
2. На базе это фреймворка разработали собственную библиотеку, которая ускоряет разработку.
3. Фреймворк и библиотека заставляют использовать определенные стандарты кодирования.
Причем это не только оформление синтаксиса кода, а и стандарты проектирования системы.
4. Если есть время каждый новый программист выполняет тестовый проект, в котором использует наработки.
Потом происходит разбор кода.
5. Сделали обучающее видео :)
В процессе — система еженедельных семинаров на интересные темы. 2 часа в неделю найти можно.
1. Сделали ставки на несколько опенсорс платформ: фреймворк и пару специфичных цмс.
2. На базе это фреймворка разработали собственную библиотеку, которая ускоряет разработку.
3. Фреймворк и библиотека заставляют использовать определенные стандарты кодирования.
Причем это не только оформление синтаксиса кода, а и стандарты проектирования системы.
4. Если есть время каждый новый программист выполняет тестовый проект, в котором использует наработки.
Потом происходит разбор кода.
5. Сделали обучающее видео :)
В процессе — система еженедельных семинаров на интересные темы. 2 часа в неделю найти можно.
Еще появилось пару модификаций внутренней библиотеки. В планах построить её разработку (даже скорее просто поплнение) по типу разработки опенсорс проекта.
Опять же с нуля никто ничего не будет разарбатывать, каждый сам за себя. Чтобы получить систееу, нужно сначала создать её, а потом заставить других в неё поверить.
Опять же с нуля никто ничего не будет разарбатывать, каждый сам за себя. Чтобы получить систееу, нужно сначала создать её, а потом заставить других в неё поверить.
4. Учет изменений на проекте и документация особенностей.
По этому вопросу я считаю следующее:
— Лучшая документация для программиста это корректно работающий код, который хорошо спроектирован и прокомментирован.
— Лучшая документация для QA это актуальный набор test cases.
— Документы по архитектуре системы, по настройкам, описание процессов деплоймента, процесса разарботки должны быть общедоступными и актуальными.
— Проект должен иметь централизованный архив документов.
— Проект дожен иметь историю итераций четко отраженную в исходном коде — ( допустим в свн для каждого релиза отдельная ветка, коммиты в свн должны быть с комментариями, комитить нужно не часы работы, а законченный куски кода)
При соблюдении этих правил по моему опыту редактировать объемное ТЗ не нужно, достаточно иметь все в архиве. Также при таком подходе вся команда — программисты, тестировщики, менеджеры, заказчики — участвует в процессе документирования своих знаний о проекте. Нужно настраивать процессы.
По этому вопросу я считаю следующее:
— Лучшая документация для программиста это корректно работающий код, который хорошо спроектирован и прокомментирован.
— Лучшая документация для QA это актуальный набор test cases.
— Документы по архитектуре системы, по настройкам, описание процессов деплоймента, процесса разарботки должны быть общедоступными и актуальными.
— Проект должен иметь централизованный архив документов.
— Проект дожен иметь историю итераций четко отраженную в исходном коде — ( допустим в свн для каждого релиза отдельная ветка, коммиты в свн должны быть с комментариями, комитить нужно не часы работы, а законченный куски кода)
При соблюдении этих правил по моему опыту редактировать объемное ТЗ не нужно, достаточно иметь все в архиве. Также при таком подходе вся команда — программисты, тестировщики, менеджеры, заказчики — участвует в процессе документирования своих знаний о проекте. Нужно настраивать процессы.
6. Замыкание многих процессов на самых компетентных и перегрузка их работой.
Проблема действительно серьезная.
Решение на мой взгляд такое:
Нужно работать с людьми, которые хотят это делать хорошо.
1. Нужно мотивировать профессионалов. Нужно создавать атмосферу, в которой приятно развиваться как профессионал и делать свою работу. Нужно искать в работе новое. Открывать горизонты. Сейчас скажут — мы не выбираем проекты, у нас все проекты говно и т.п. Могу сказать одно — любую работу можно сделать плохо, посредственно, хорошо и великолепно. Стремится нужно к последнему.
2. Есть люди, с которыми просто не по пути. Расставание всегда означает новые встречи. Не сидите на месте когда тошно, дайте шанс себе и работодателю — либо измените отношение либо увольтесь. То же самое с работодателями — либо менять отношение либо увольнять.
Хорошо работать невозможно заставить, можно только мотивировать.
Проблема действительно серьезная.
Решение на мой взгляд такое:
Нужно работать с людьми, которые хотят это делать хорошо.
1. Нужно мотивировать профессионалов. Нужно создавать атмосферу, в которой приятно развиваться как профессионал и делать свою работу. Нужно искать в работе новое. Открывать горизонты. Сейчас скажут — мы не выбираем проекты, у нас все проекты говно и т.п. Могу сказать одно — любую работу можно сделать плохо, посредственно, хорошо и великолепно. Стремится нужно к последнему.
2. Есть люди, с которыми просто не по пути. Расставание всегда означает новые встречи. Не сидите на месте когда тошно, дайте шанс себе и работодателю — либо измените отношение либо увольтесь. То же самое с работодателями — либо менять отношение либо увольнять.
Хорошо работать невозможно заставить, можно только мотивировать.
>1. Нужно мотивировать профессионалов. Нужно создавать атмосферу, в которой приятно развиваться как профессионал и делать свою работу. Нужно искать в работе новое. Открывать горизонты. Сейчас скажут — мы не выбираем проекты, у нас все проекты говно и т.п. Могу сказать одно — любую работу можно сделать плохо, посредственно, хорошо и великолепно. Стремится нужно к последнему.
а это очень правильно сказано.
а это очень правильно сказано.
По моему мнению универсального решения всех пунктов (или по каждому отдельного) нету, собственного и тем отличаються разные студии или компании что одни как все делаю четке, а у других как так не все гладко :).
У Лебедева кстати по этому есть особое мнение: Догоро. Долго. Охуенно. (и он прав, така уже наша доля… ИТ — издержки профессии, как любят говорить. )
У Лебедева кстати по этому есть особое мнение: Догоро. Долго. Охуенно. (и он прав, така уже наша доля… ИТ — издержки профессии, как любят говорить. )
Насчёт последнего пункта (охуенно) можно поспорить. Но вот пиар у студии налажен запредельно офигенно и эффективно. Они очень и очень здорово умеют себя продавать, чего очень сильно не хватает другим фирмам.
> Денег на исправление нет никогда. Такой проект становится кошмаром для support.
заказчик может как раз выдавать такие проекты «командам 911», которые его будут реанимировать, реверсинжинирить и потом документировать/технологизировать. Есть конторы, которые только на том и живут — реанимировать до состояния «уже дышит, но еще не двигается», а на выздоровление проект отправляется индийскому-русскому-китайскому-итп аутсорсам. Выздоровления часто не наблюдается, и в конце цикла проект опять попадает в реанимацию. Для «команд скорой помощи» это как раз неисчерпаемый источник доходов.
заказчик может как раз выдавать такие проекты «командам 911», которые его будут реанимировать, реверсинжинирить и потом документировать/технологизировать. Есть конторы, которые только на том и живут — реанимировать до состояния «уже дышит, но еще не двигается», а на выздоровление проект отправляется индийскому-русскому-китайскому-итп аутсорсам. Выздоровления часто не наблюдается, и в конце цикла проект опять попадает в реанимацию. Для «команд скорой помощи» это как раз неисчерпаемый источник доходов.
> Выделение ресурса на процесс контроля и прямое отражение этой статьи в затратах.
еще практика: все осуществляют контроль за свои деньги-время. Иногда заказчик вообще не заказывает в проект PMа, а только непосредственных исполнителей, и PMит на своей стороне, но при этом продолжает спрашивать аналитику по команде. Получается, разработчик тратит от 30 минут до 2 часов в день на бумажную работу и анализ (как для себя как для участника проекта, как для удаленного сотрудника заказчика, как для участника проекта своей компании, как для офисного работника своей компании), которые он не может записать в оплаченные часы. Рабочий день из любого количества часов превращается в 10-часовой.
еще практика: все осуществляют контроль за свои деньги-время. Иногда заказчик вообще не заказывает в проект PMа, а только непосредственных исполнителей, и PMит на своей стороне, но при этом продолжает спрашивать аналитику по команде. Получается, разработчик тратит от 30 минут до 2 часов в день на бумажную работу и анализ (как для себя как для участника проекта, как для удаленного сотрудника заказчика, как для участника проекта своей компании, как для офисного работника своей компании), которые он не может записать в оплаченные часы. Рабочий день из любого количества часов превращается в 10-часовой.
в смысле, это плохо.
Необходимо сразу закладывать это время в смету.
Если заказчик хочет отчетности — на нее нужно время.
Если это время забирается у разработчиков — это косяк управления, с этим надо бороться.
Если оно сознательно забирается у разработчиков — это эксплуатация, от таких надо просто валить. Исключение только в том случае, если разработчик в доле.
Если заказчик хочет отчетности — на нее нужно время.
Если это время забирается у разработчиков — это косяк управления, с этим надо бороться.
Если оно сознательно забирается у разработчиков — это эксплуатация, от таких надо просто валить. Исключение только в том случае, если разработчик в доле.
НЛО прилетело и опубликовало эту надпись здесь
10 пункт решается внедрением методик управления знаниями, это целая парадигма ведения бизнеса. На западе это направление уже входит в силу, в России я знаю только одних ребят, которые действительно шарят в этой области: knowledgemanagement.ru/
План управления рисками проекта — будет хорошим документом, тем более, что база рисков у вас набралась уже. И для заказчиков этот документ будет полезным.
По поводу 10.
Нужно иметь хотя бы несколько выполненных проектов близких предметных областей, чтобы можно было переиспользовать прошлый опыт. Причем переиспользовать код, как правило, удается только для всяких утилитных вещей. Можно делать по аналогии — это все равно намного дешевле, чем писать «с нуля». И забудьте про серебрянные пули — их не бывает.
Чтобы переиспользование опыта старых проектов, он должен быть задокументирован. Документации подлежат:
Мотивацией документирования может служить опыт успешных разработок, которые без документации никогда бы не выжили. Например, те же используемые framework'и. Нужно четко увязать в головах зависимость между управляемостью проекта и документацией. Каждый должен понимать, что если сегодня он это не задокументирует, то завтра он наткнется на чужой код, который кто-то не задокументировал, и положит кучу времени на анализ.
В обязательном порядке необходимо осуществлять проверку качества документации на предмет содержания в ней всех деталей из указанного выше списка. Если чего-то не хватает — необходимо явно указывать на это и добавлять (все мы люди, все ошибаемся). Должно быть понимание, что качественная документация является показателем профессионализма, что бы там не говорили. IMHO, профессионал всегда способен четко изложить детали. Оформлением может заниматься кто-то еще, но полноту информации должен обеспечить разработчик.
Нужно иметь хотя бы несколько выполненных проектов близких предметных областей, чтобы можно было переиспользовать прошлый опыт. Причем переиспользовать код, как правило, удается только для всяких утилитных вещей. Можно делать по аналогии — это все равно намного дешевле, чем писать «с нуля». И забудьте про серебрянные пули — их не бывает.
Чтобы переиспользование опыта старых проектов, он должен быть задокументирован. Документации подлежат:
- все нетривиальные алгоритмы;
- все компоненты и расширения используемых framework'ов;
- высокоуровневая модель компонентов системы;
- сложные системы взаимодействия для выполнения какой-то узкой задачи (например, progress bar'ы для веба) — и диаграммы, и текстовое описание (и то, и другое необходимо);
- при выполнении для нескольких заказчиков — четко фиксировать участки, специфичные для заказчика;
- все детали, специально проясненные у заказчика (резюме переписок и устных бесед);
- все локальные решения и предположения, принятые в обход заказчика (с указанием причин выбора);
Мотивацией документирования может служить опыт успешных разработок, которые без документации никогда бы не выжили. Например, те же используемые framework'и. Нужно четко увязать в головах зависимость между управляемостью проекта и документацией. Каждый должен понимать, что если сегодня он это не задокументирует, то завтра он наткнется на чужой код, который кто-то не задокументировал, и положит кучу времени на анализ.
В обязательном порядке необходимо осуществлять проверку качества документации на предмет содержания в ней всех деталей из указанного выше списка. Если чего-то не хватает — необходимо явно указывать на это и добавлять (все мы люди, все ошибаемся). Должно быть понимание, что качественная документация является показателем профессионализма, что бы там не говорили. IMHO, профессионал всегда способен четко изложить детали. Оформлением может заниматься кто-то еще, но полноту информации должен обеспечить разработчик.
>>Текучка на проекте – уходят те, кто «в теме», а набирают тех, кто найдут
Чтобы постоянно иметь несколько разработчиков «в теме», полезно проводить регулярный code review. Времени занимает немного — 15-30 минут в неделю, зато всёгда есть 1-2 человека, хорошо разбирающихся в чужом коде.
Чтобы постоянно иметь несколько разработчиков «в теме», полезно проводить регулярный code review. Времени занимает немного — 15-30 минут в неделю, зато всёгда есть 1-2 человека, хорошо разбирающихся в чужом коде.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Основные проблемы проектного менеджера и как с ними бороться