nori @00oichan お気軽にフォローいただけると嬉しいです。 神奈川県在住/運用設計が得意/外資系企業のSaaSエンジニアです。 好き: servicenow,生成AI,UiPath,Power Automate Desktop,PowerBI … Amazon.co.jp アソシエイトを利用中です
![要件定義に関わる人は3億回くらい読んでほしい−−−−−−−−−−「IPA 独立行政法人 情報処理推進機構 超上流から攻める IT 化の原理原則 17ヶ条」](https://cdn-ak-scissors.b.st-hatena.com/image/square/08bc09c124daadd456829454e7f6e58f0fe3c0f1/height=288;version=1;width=512/https%3A%2F%2Fs.togetter.com%2Fogp2%2F6da1656549d85ad7dc41d2063e0f6813-1200x630.png)
たまに、今のこの状況は組織パターンに載ってたこのパターンだ、と思い出すことがある。数年前に読んでまだ役立ってる本のうちのひとつ。 今は「常に誰かが進捗させる」というプラクティスをやっている。それ自体はいいのだけど、問題なのは、チーム内チームのエンジニア二人チームでやっているので、一人が進捗させる、もう一人が差し込み対応する、という最小の形になっていること。 奥さんが家でやってる生け花教室のホームページを作る夫、みたいなものをイメージすると、奥さんが生花を教えることで進捗させて、夫がホームページ更新など雑務を巻き取るという構造をイメージできる。百人以上の人間がいる会社であっても、夫婦の生け花教室と同じ数の人のアサインでことを進めているのだとしたら、推進力では同じくらいしか出せないはず。実際には百人いる会社には経理の人がいたり総務の人が居たり、資本が潤沢にあったら良いパソコンを使えるとか、いろ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く