Чтобы не попасть в кризис роста, надо не допускать роста :-) Есть замечательная книга От хорошего к великому, в которой описаны различные стратегии увеличения прибыли компании. Одна из них — повышение прибыли в пересчете на одного сотрудника. Мы выбрали именно ее. В этих условиях бурный рост необязателен.
Увеличение численности — соблазнительный путь, поскольку прост. Но он экстенсивный. Японцы научились выращивать редьку и свеклу, которая вглубь на метр уходит, а по площади поверхности земли, занимаемой на огороде — как обычная. Про канбан с его постоянным сокращением издержек и повышением прибыли я и не говорю.
Соответственно, чтобы увеличивать прибыль на сотрудника, надо иметь очень прокачанную и самомотивированную команду (очень рекомендую доклад Дмитрия Лобасева про«внутреннюю морковку», смеялись до слез), а так же автоматизировать все, что только можно, чтобы сократить издержки на разработку.
Тут уже звучало, что метод не промышленный — ну может и так, а на мой взгляд для аутсорсеров — самое то.
Направление — это уже полдела. Ну и сейчас счастье присутствует, только не со всеми заказчиками еще полная гармония. Надеюсь, что скоро позволим себе выбирать, как Злые марсиане, например. Это, кстати, для нас пример, что это все может сработать.
Ну меня «стабильность» и деньги уже давно не мотивируют. «Я не хочу ничего решать, я хочу просто писать код» — тоже не наш принцип. Стараемся наносить непоправимую пользу, как говорит дядя Слава Панкратов, по мере сил. И только в этом я вижу смысл нашей работы.
Я подумала, что вполне можно сделать видео-лекции. Надо в следующем году сделать. Начать с вебинаров и записывать их. Да и слайды не помешают. В-общем, надеюсь, что времени хватит
Я, например, читаю спецкурс в ОмГУ, основная цель которого — ликвидировать разрыв между вузом и требованиями работодателя. Студенты выполняют web-проекты в процессе и изучают все необходимое для реальной работы — системы контроля версий, пробуют командную работу, таск-трекеры, автоматизацию тестирования и многое другое.
Но это — исключительно частная инициатива. Я за много лет работы в индустрии пришла к выводу, что надо просто идти в вуз и делать. А самим вузам это как правило до лампочки. Да и преподаватели давно оторваны от реальности.
Есть одно важное замечание: фундаментальные математические курсы, всякие там структуры данных, методы трансляции, реляционная алгебра — это все обязательно должно быть, и пусть этому учат в вузе. А для практики достаточно одного годового курса и небольшой стажировки.
Первый выпуск спецкурса отработал уже 2 года, в том числе у меня в компании. Я довольна :-)
Так что ищите заинтересованных работодателей, приглашайте, они будут счастливы научить себе сотрудников.
Вы знаете, что такое User story, test cases, acceptance criteria в SCRUM? Видимо, нет. Посмотрите — лишним не будет. agiledays.ru — вот сюда еще можно съездить — узнаете массу нового :-)
Отсутствие ТЗ в общепринятом понимании не означает бардак и непонимание целей, как раз с точностью до наоборот, если речь идет о SCRUM.
Однако, мы сильно отклонились от темы, это можно и в кулуарах обсудить.
Начинающему ТЗ может пойти и во вред. Увидит человек некий внушительный документ на N страницах, может и не смочь толком вникнуть к него. Согласится. А как читать начнет… Тут xxx раем покажется :-)
Я еще ни разу не видела внятного ТЗ от заказчика, которое не было бы полно воды, неучтенных моментов и противоречий. ТЗ = ХЗ, как говорится.
Способ описания разный. Критерии приемки в скраме — это готовые тест кейсы. Вот прямо по ним идешь и показываешь: дергаем за эту пимпочку, получаем фиговинку, а если при этом вон та фитюлька нажата, то хреновинку. Для демонстрации готового результата очень удобно. И для общего одинакового понимания, что именно заказчик получит в результате.
Увеличение численности — соблазнительный путь, поскольку прост. Но он экстенсивный. Японцы научились выращивать редьку и свеклу, которая вглубь на метр уходит, а по площади поверхности земли, занимаемой на огороде — как обычная. Про канбан с его постоянным сокращением издержек и повышением прибыли я и не говорю.
Соответственно, чтобы увеличивать прибыль на сотрудника, надо иметь очень прокачанную и самомотивированную команду (очень рекомендую доклад Дмитрия Лобасева про«внутреннюю морковку», смеялись до слез), а так же автоматизировать все, что только можно, чтобы сократить издержки на разработку.
Тут уже звучало, что метод не промышленный — ну может и так, а на мой взгляд для аутсорсеров — самое то.
Изначально я хотела отделить то, что желательно прочитать, от баек. Но попросили убрать форматирование.
Я привыкла к такой реакции :-) Не обращаю внимания.
Спасибо, что осилили, судя по минусам — не всем это удалось.
Но это — исключительно частная инициатива. Я за много лет работы в индустрии пришла к выводу, что надо просто идти в вуз и делать. А самим вузам это как правило до лампочки. Да и преподаватели давно оторваны от реальности.
Есть одно важное замечание: фундаментальные математические курсы, всякие там структуры данных, методы трансляции, реляционная алгебра — это все обязательно должно быть, и пусть этому учат в вузе. А для практики достаточно одного годового курса и небольшой стажировки.
Первый выпуск спецкурса отработал уже 2 года, в том числе у меня в компании. Я довольна :-)
Так что ищите заинтересованных работодателей, приглашайте, они будут счастливы научить себе сотрудников.
Отсутствие ТЗ в общепринятом понимании не означает бардак и непонимание целей, как раз с точностью до наоборот, если речь идет о SCRUM.
Однако, мы сильно отклонились от темы, это можно и в кулуарах обсудить.
Начинающему ТЗ может пойти и во вред. Увидит человек некий внушительный документ на N страницах, может и не смочь толком вникнуть к него. Согласится. А как читать начнет… Тут xxx раем покажется :-)
Я еще ни разу не видела внятного ТЗ от заказчика, которое не было бы полно воды, неучтенных моментов и противоречий. ТЗ = ХЗ, как говорится.
А я про то, что получается и еще как. Проверено практикой.
Скоро сделаем конференцию на тему, отпишусь.